From superuser@gmail.com Fri Jun 1 20:49:02 2012 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 CFE4C11E80EC for ; Fri, 1 Jun 2012 20:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-mEd4-1eT1t for ; Fri, 1 Jun 2012 20:49:02 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A01111E808C for ; Fri, 1 Jun 2012 20:49:01 -0700 (PDT) Received: by lagv3 with SMTP id v3so2124480lag.31 for ; Fri, 01 Jun 2012 20:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Lm9uy+qP9Pk69X0XoDwrL8mFe2nSe2AVxXVKV1YB7ok=; b=qDC28BRq8GqnCYDQ3JOih1Scpu5b0j6b+tv9O/x9VJmGtsiJrwcjac1q2Ot4NarGqR TM8ubTHE2JjA7S49uqkl35CnqC0ikT10Zva06jhkxXZ16l9kAw86m6G5layny0hpUIeZ eVz06LiB796YXYUFq0iiY90S4mmHF0oUv9Kh4diKUFy9yJsGsa64Fe/n0he1L65pkAN+ AnKtb8X9DRr7MRTuRMEVcEqDbWUaELo/5Dvobg5X8Zy6D6VaoV3eVO2xqfU38MihkYc0 WO4UTwaMEfosgQ4hja7MZXRs2b93EdzR83dxqvcG8Z8c42hHFkpzXREmp+WbQ74e1qoT S87Q== MIME-Version: 1.0 Received: by 10.112.39.135 with SMTP id p7mr2936123lbk.78.1338608941066; Fri, 01 Jun 2012 20:49:01 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Fri, 1 Jun 2012 20:49:01 -0700 (PDT) Date: Fri, 1 Jun 2012 20:49:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: weirds@ietf.org Content-Type: multipart/alternative; boundary=485b390f7a766ceb1f04c1752e13 Subject: [weirds] Change of address 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, 02 Jun 2012 03:49:02 -0000 --485b390f7a766ceb1f04c1752e13 Content-Type: text/plain; charset=ISO-8859-1 Hi all, quick administrative note: With a change in employers comes a change in address. My IETF activity now lives at this one. All of the datatracker and tools aliases have been updated, so replies to those will now come to me here with no action needed by you. Direct replies to my old address will bounce after Sunday, and I may not notice them before then. Please update your address books accordingly. Have a good weekend, -MSK, APPSAWG and WEIRDS co-chair --485b390f7a766ceb1f04c1752e13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, quick administrative note:

With a change in employers comes a change in address.=A0 My IETF activity n= ow lives at this one.

All of the datatracker and tools aliases have been updated, so replies=20 to those will now come to me here with no action needed by you.=A0 Direct= =20 replies to my old address will bounce after Sunday, and I may not notice them before then.=A0 Please update your address books accordingly.

Have a good weekend,

-MSK, APPSAWG and WEIRDS co-chair
--485b390f7a766ceb1f04c1752e13-- From nkong@cnnic.cn Sun Jun 3 00:39:34 2012 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 348A921F857D for ; Sun, 3 Jun 2012 00:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPOB3wiXHPlj for ; Sun, 3 Jun 2012 00:39:33 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id DB08C21F8573 for ; Sun, 3 Jun 2012 00:39:32 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 03 Jun 2012 15:39:28 +0800 From: "Ning Kong" To: References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> In-Reply-To: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> Date: Sun, 3 Jun 2012 15:39:27 +0800 Message-ID: <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJi3VEHK9xKwykB9g8h5PS1Ivn8ipW89iNw Content-Language: zh-cn Subject: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 07:39:34 -0000 Hi all, This is a 00 draft to describe a response format in JSON for name registries. This document has been reviewed and improved by the design team. The following issues are still needed to be further discussed. 1) As for the naming of the terms, should we try to follow the EPP specs or just use some more self-descriptive and unified terms? For example, "roid" or "domainID" for naming the ID of domain object, which one is better? 2) Is the extension interface necessary or not? Any comments are appreciated. Cheers, Ning -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Sunday, June 03, 2012 3:12 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-kong-dnrd-ap-response-json-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name Registration Data Access Protocol Response Format defined in JSON Author(s) : Ning Kong Linlin Zhou Jiagui Xie Sean Shen Filename : draft-kong-dnrd-ap-response-json-00.txt Pages : 21 Date : 2012-06-03 This document describes a response format for registration data (Whois data) through RESTful Web-based Service. This response format is defined in JavaScript Object Notation (JSON). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kong-dnrd-ap-response-json-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-kong-dnrd-ap-response-json-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-kong-dnrd-ap-response-json/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From olaf@nlnetlabs.nl Tue Jun 5 03:37:51 2012 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 3D79621F86E1 for ; Tue, 5 Jun 2012 03:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.46 X-Spam-Level: X-Spam-Status: No, score=-101.46 tagged_above=-999 required=5 tests=[AWL=1.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LG73wQ5ZQrl for ; Tue, 5 Jun 2012 03:37:50 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5285821F86E2 for ; Tue, 5 Jun 2012 03:37:49 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q55AbjYI080897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 5 Jun 2012 12:37:46 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1338892667; bh=By6ngwMkHpUM3fmA4mUMr926eshRVEepfloVTxoDhnQ=; h=From:Subject:Date:To; b=njjhudcP9IozrfwL1YlXphZwcL4BNaKr+nm9DRnDDpr0gJw/5KxrZQpcnp0r2yZCr kpp0uku+gvt/eisZFO1GtQCwVMoPwS6OLUuENXOGVg+0z2x7jfIUcX2RfT4NmAb9w6 hDIellEhwQYF/yH1wXaiq9GppF6rs9intp/ROHf0= From: Olaf Kolkman Content-Type: multipart/signed; boundary="Apple-Mail=_3879EDF9-C92E-48DC-AB60-7516AEAD49E6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Tue, 5 Jun 2012 12:37:29 +0200 Message-Id: To: Web Extensible Internet Registration Data Service Working Group Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Tue, 05 Jun 2012 12:37:46 +0200 (CEST) Subject: [weirds] Divide and Conquer 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, 05 Jun 2012 10:37:51 -0000 --Apple-Mail=_3879EDF9-C92E-48DC-AB60-7516AEAD49E6 Content-Type: multipart/alternative; boundary="Apple-Mail=_0B85FB07-0E06-4979-B0AF-D8ED987E52C4" --Apple-Mail=_0B85FB07-0E06-4979-B0AF-D8ED987E52C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Colleagues, Murray and myself have been talking to a few active working = participants, with the area director, and among ourselves.=20 Based on those discussion, and after coordination with Murray, I would like to make two proposals for getting work done: 1. Working group drafts and output documents. Murray has already called for adaption of a number of documents. Those documents are all input documents. The output of the working group might find its way into a different set of documents. A structure that has been proposed to me by Scott H. and Andy N. seems = reasonable:=20 1. For all implementers: 1.1 The use of HTTP 1.2 Details of Redirecting 1.3 Specification of generic json responses and extensibility = mechanism 1.4 Specification of generic xml responses and extensibility mechanism 2.Numbers: 2.1 specification of queries 2.2 specification of specific number-responses json responses 3.Names: 3.1 specification of queries 3.2 specification of specific name-related json responses=20 and/or 3.3 specification of specific number-related xml responses It might be that 1.3 and 1.4 are so minimal that the information therein is better (dublicated) in 2.2, 3.2, and 3.3. 2. Dealing with the data framework. I believe that the data framework for the domain name space is one of the biggest elephants in the room and that making sure we converge to a comon understanding is critical to success of the working group. It seems that an enumeration of all data elements that are comonly in use including comonly used formats. Ray Bellis and Frederico Neves have made a start with that in a spreadsheet at = https://docs.google.com/spreadsheet/ccc?key=3D0AjZQpmBlboLWdFBfdERTQm9QQWd= rejNtaTBhNmI3SHc#gid=3D0 and it seems that we can use that as a basis. Once we have a relatively complete enumeration of all data elements that are commonly in use we continue with trying to get convergence on their presentation format (it seems we have to do that irrespective of encaptulation in json or xml). One of the important questions that might help to converge while defining data elements and while determining such data-element can be queried is whether the query-response protocol is direct match, or search. The charter is not clear about this, I believe. Hence I propose that we focus on the low-hanging fruit of direct-match and that we circumvent any questions of the type 'what type of matching algorithm to apply?'=20 For instance, if we have a person name as a data element then a query for "Kolkman" might not yield a unique result and some matching algorithm may need to be applied, the use of a NIC-handle might be more appropriate in such cases. By agreeing on the principle that we work towards direct-match we know how to focus our energy. How does this sound as a first order approach? If folk like this we'll try to come up with a way to capture the information in the spreadsheet (or other appropriate tool) and work forward in a structured way. --Olaf=20 WEIRDS co-chair NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_0B85FB07-0E06-4979-B0AF-D8ED987E52C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear Colleagues,

Murray and = myself have been talking to a few active working participants, with the = area director, and among ourselves. 

Based = on those discussion, and after coordination with Murray, I = would
like to make two proposals for getting work = done:


1. Working group drafts = and output documents.

Murray has already called = for adaption of a number of documents. Those
documents are all = input documents. The output of the working group
might find = its way into a different set of documents.

A = structure that has been proposed to me by Scott H. and Andy N. seems = reasonable: 

1. For all = implementers:
  1.1 The use of HTTP
  1.2 = Details of Redirecting

  1.3 Specification = of generic json responses and extensibility mechanism
  = 1.4 Specification of generic xml responses and extensibility = mechanism

2.Numbers:
  2.1 = specification of queries
  2.2 specification of specific = number-responses json = responses

3.Names:
  3.1 = specification of queries
  3.2 specification of specific = name-related json responses 
and/or
  3.3 = specification of specific number-related xml = responses


It might be that 1.3 = and 1.4 are so minimal that the information
therein is better = (dublicated) in 2.2, 3.2, and = 3.3.



2. Dealing = with the data framework.

I believe that the = data framework for the domain name space is one of
the biggest = elephants in the room and that making sure we converge to
a = comon understanding is critical to success of the working group. = It
seems that an enumeration of all data elements that are = comonly in use
including comonly used formats. Ray Bellis and = Frederico Neves
have made a start with that in a spreadsheet = at
and it seems = that we can use that as a basis.

Once we have a = relatively complete enumeration of all data elements
that are = commonly in use we continue with trying to get convergence = on
their presentation format (it seems we have to do that = irrespective of
encaptulation in json or = xml).

One of the important questions that might = help to converge while
defining data elements and while = determining such data-element can be
queried is whether the = query-response protocol is direct match, or
search. The = charter is not clear about this, I believe. Hence I
propose = that we focus on the low-hanging fruit of direct-match = and
that we circumvent any questions of the type 'what type of = matching
algorithm to = apply?' 

For instance, if we have a person = name as a data element then a query
for "Kolkman" might not = yield a unique result and some matching
algorithm may need to = be applied, the use of a NIC-handle might be
more appropriate = in such cases. By agreeing on the principle that we
work = towards direct-match we know how to focus our = energy.

How does this sound as a first order = approach? If folk like this we'll
try to come up with a way to = capture the information in the spreadsheet
(or other = appropriate tool) and work forward in a structured = way.

--Olaf 
  WEIRDS = co-chair

Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_0B85FB07-0E06-4979-B0AF-D8ED987E52C4-- --Apple-Mail=_3879EDF9-C92E-48DC-AB60-7516AEAD49E6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPzeFqAAoJEFRqER47aqpk+0cP/Rsd+PunwiYXf9utBm/Axlh2 rloNTqdPIy3yn+HuwNCGDTd8pTUbqDfkruHMbfL/D/OrqctV7yONJRffdiocsv46 7XD/2XSqqe6lNs4iMkVfLM++LiF0W36Ut9HLFpVOu0OCpLgoVa8O5VLiLF7oBzig G/5hVOEg5QniFICZn8E+w1gpIkhKL09e6P3DojoGAL04yyi1tRWrVvNArSEPdTEz X8LGioQOoEP2qVi5ZeUGUmjzfC+YI5A4xN9zSYArMO5ivj3ZHiUkpGkEG5tPGTqq N00fnmP7nFtkuGqST+mRRNwzTGljZ1Gxu1OVZUtRE0BsLxSXr0weT5YbB3yJYgkJ zbCEsokvRHJ7OXT7J2YZPt+L2UD3OFPAEnC7bNrUpDXZ31j61GkJOMk8AK9YgMN1 5k/mYQxIXYG+nj0nIsrLT+w4aY8z11w7if1rzOpuC95G6HyEfOk201a2Mz/cxIGB GyUx6j/l3OYMk5h8C3Q3DK3DMYZNrlPvjnDy30CT0IPFrGvVJ6IyOnIasMJRiAmQ 83KHLvt08fxDFuKgvQu0k/+HcXyvc5h46d+R1SMAvRBzcgoO1I7aBDC+pQzjIa0k piYCDlDZug1PfYgovFAvcPUe/42zE4hlgvIljeOtKRTnQNbY3w2pliFYqbct697M hpGcWAVh3jeDb5Ao4B6y =NzZF -----END PGP SIGNATURE----- --Apple-Mail=_3879EDF9-C92E-48DC-AB60-7516AEAD49E6-- From steve.sheng@icann.org Tue Jun 5 11:06:10 2012 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 13DDE21F861E for ; Tue, 5 Jun 2012 11:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SojfvY3cWPR for ; Tue, 5 Jun 2012 11:06:08 -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 99E4F21F854F for ; Tue, 5 Jun 2012 11:06:08 -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, 5 Jun 2012 11:06:08 -0700 From: Steve Sheng To: Olaf Kolkman , Web Extensible Internet Registration Data Service Working Group Date: Tue, 5 Jun 2012 11:06:07 -0700 Thread-Topic: [weirds] Divide and Conquer Thread-Index: Ac1DReG5vC16v75TT9mUjyljzjN63g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBF38FE51D74Bsteveshengicannorg_" MIME-Version: 1.0 Subject: Re: [weirds] Divide and Conquer 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, 05 Jun 2012 18:06:10 -0000 --_000_CBF38FE51D74Bsteveshengicannorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Olaf, From: Olaf Kolkman > To: Web Extensible Internet Registration Data Service Working Group > Subject: [weirds] Divide and Conquer Dear Colleagues, Murray and myself have been talking to a few active working participants, w= ith the area director, and among ourselves. Based on those discussion, and after coordination with Murray, I would like to make two proposals for getting work done: 1. Working group drafts and output documents. Murray has already called for adaption of a number of documents. Those documents are all input documents. The output of the working group might find its way into a different set of documents. A structure that has been proposed to me by Scott H. and Andy N. seems reas= onable: 1. For all implementers: 1.1 The use of HTTP 1.2 Details of Redirecting 1.3 Specification of generic json responses and extensibility mechanism 1.4 Specification of generic xml responses and extensibility mechanism 2.Numbers: 2.1 specification of queries 2.2 specification of specific number-responses json responses 3.Names: 3.1 specification of queries 3.2 specification of specific name-related json responses and/or 3.3 specification of specific number-related xml responses It might be that 1.3 and 1.4 are so minimal that the information therein is better (dublicated) in 2.2, 3.2, and 3.3. I support the approach outlined above. 2. Dealing with the data framework. I believe that the data framework for the domain name space is one of the biggest elephants in the room and that making sure we converge to a comon understanding is critical to success of the working group. It seems that an enumeration of all data elements that are comonly in use including comonly used formats. Ray Bellis and Frederico Neves have made a start with that in a spreadsheet at https://docs.google.com/spreadsheet/ccc?key=3D0AjZQpmBlboLWdFBfdERTQm9QQWdr= ejNtaTBhNmI3SHc#gid=3D0 and it seems that we can use that as a basis. I volunteer to help with this effort, and will produce such list for for gT= LD registries and registrars shortly as a starting point. We could also hel= p / facilitate reaching out to ccTLDs if needed. Once we have a relatively complete enumeration of all data elements that are commonly in use we continue with trying to get convergence on their presentation format (it seems we have to do that irrespective of encaptulation in json or xml). I volunteer to help with this effort as well. There will be ICANN work on d= ata models (called by the SSAC and Whois review team), I see both efforts s= imilar and perhaps can collaborate / communicate. One thought though, this = effort should not prescribe policy (e.g. What mandatory data elements to di= splay), but should merely enable it. (e.g. If your policy asks to display X= Y and Z, here is how to do it in a way that supports internationalization)= . One of the important questions that might help to converge while defining data elements and while determining such data-element can be queried is whether the query-response protocol is direct match, or search. The charter is not clear about this, I believe. Hence I propose that we focus on the low-hanging fruit of direct-match and that we circumvent any questions of the type 'what type of matching algorithm to apply?' Agree. Francisco suggested earlier that moving the non direct-match into a = second draft that focuses on searches. For instance, if we have a person name as a data element then a query for "Kolkman" might not yield a unique result and some matching algorithm may need to be applied, the use of a NIC-handle might be more appropriate in such cases. By agreeing on the principle that we work towards direct-match we know how to focus our energy. How does this sound as a first order approach? If folk like this we'll try to come up with a way to capture the information in the spreadsheet (or other appropriate tool) and work forward in a structured way. --Olaf WEIRDS co-chair NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --_000_CBF38FE51D74Bsteveshengicannorg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Olaf, 

From: Olaf Kolkman= <olaf@nlnetlabs.nl>
To: Web Extensible Internet Registrati= on Data Service Working Group <weirds= @ietf.org>
Subject: [wei= rds] Divide and Conquer


Dear Collea= gues,

Murray and myself have been talking to a few= active working participants, with the area director, and among ourselves.&= nbsp;

Based on those discussion, and after coordin= ation with Murray, I would
like to make two proposals for getting= work done:


1. Working group drafts= and output documents.

Murray has already called f= or adaption of a number of documents. Those
documents are all inp= ut documents. The output of the working group
might find its way = into a different set of documents.

A structure tha= t has been proposed to me by Scott H. and Andy N. seems reasonable: 

1. For all implementers:
  1.1 The u= se of HTTP
  1.2 Details of Redirecting

=
  1.3 Specification of generic json responses and extensibility m= echanism
  1.4 Specification of generic xml responses and ex= tensibility mechanism

2.Numbers:
  = 2.1 specification of queries
  2.2 specification of specific= number-responses json responses

3.Names:
  3.1 specification of queries
  3.2 specification of= specific name-related json responses 
and/or
&nbs= p; 3.3 specification of specific number-related xml responses

It might be that 1.3 and 1.4 are so minimal that= the information
therein is better (dublicated) in 2.2, 3.2, and = 3.3.

=

I support the approach outlined above.



2. D= ealing with the data framework.

I believe that the= data framework for the domain name space is one of
the biggest e= lephants in the room and that making sure we converge to
a comon = understanding is critical to success of the working group. It
see= ms that an enumeration of all data elements that are comonly in use
including comonly used formats. Ray Bellis and Frederico Neves
have made a start with that in a spreadsheet at
and it seems that we can use that as a basis.

I volunteer to help with thi= s effort, and will produce such list for for gTLD registries and registrars= shortly as a starting point. We could also help / facilitate reaching out = to ccTLDs if needed. 


Once we have a relatively complete enumeration of= all data elements
that are commonly in use we continue with tryi= ng to get convergence on
their presentation format (it seems we h= ave to do that irrespective of
encaptulation in json or xml).

I v= olunteer to help with this effort as well. There will be ICANN work on data= models (called by the SSAC and Whois review team), I see both efforts simi= lar and perhaps can collaborate / communicate. One thought though, this eff= ort should not prescribe policy (e.g. What mandatory data elements to displ= ay), but should merely enable it. (e.g. If your policy asks to display X Y = and Z, here is how to do it in a way that supports internationalization). &= nbsp;


<= div>One of the important questions that might help to converge while
<= div>defining data elements and while determining such data-element can be
queried is whether the query-response protocol is direct match, or=
search. The charter is not clear about this, I believe. Hence I<= /div>
propose that we focus on the low-hanging fruit of direct-match an= d
that we circumvent any questions of the type 'what type of matc= hing
algorithm to apply?'

Agree. Francisco suggested earlier that= moving the non direct-match into a second draft that focuses on searches.&= nbsp;


<= div>For instance, if we have a person name as a data element then a query
for "Kolkman" might not yield a unique result and some matching
algorithm may need to be applied, the use of a NIC-handle might be<= /div>
more appropriate in such cases. By agreeing on the principle that= we
work towards direct-match we know how to focus our energy.

How does this sound as a first order approach? If fo= lk like this we'll
try to come up with a way to capture the infor= mation in the spreadsheet
(or other appropriate tool) and work fo= rward in a structured way.

--Olaf 
=   WEIRDS co-chair
<= div style=3D"word-wrap: break-word; ">


NLnet
Labs
Olaf M. Kolkman


Science Park 400, 1098 XH Amsterda= m, The Netherlands



 --_000_CBF38FE51D74Bsteveshengicannorg_-- From alexandrsergeyev@gmail.com Mon Jun 11 13:51:51 2012 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 9C75D21F856D for ; Mon, 11 Jun 2012 13:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Q6cVGWq4au8 for ; Mon, 11 Jun 2012 13:51:50 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5C821F856C for ; Mon, 11 Jun 2012 13:51:50 -0700 (PDT) Received: by werb13 with SMTP id b13so3593419wer.31 for ; Mon, 11 Jun 2012 13:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QJwzTJdhqbkQPLA1S+b8SHInIeJd3VNSkiGPgltuEL0=; b=A3CzSRgpdjeDEI9dNvIoCww4QCnFQCXZmE7lNTpQXB+ntnuzpLDF+Bi5QCMCthUPtY 4pSwZi3fteXmI6nxmR3iLXZPC6zcXSudHUAAGVq7A8Tm3sW057jifv0UBzT6kI8VIl6L L6ypgMUbzvU/jDcPGQNmRTxDlyq2D+q/UL6jNJ6cOG5TrYpbdTETsjwqu2Z/frO1vR+V cquENBMgnPQw81/Kw3/vfp7iOmbxfxFm+zdjIvRI4HSJ98o2nUBaEZFiQUoOcs4Z2UxZ ttsXhSCA6SfojduFwi/0vhDU8ps+hnvxo7zne/QU5wMW6ySCbJUUIOBVpHWXXVHSxh6v WS4A== MIME-Version: 1.0 Received: by 10.180.91.109 with SMTP id cd13mr23926282wib.22.1339447909571; Mon, 11 Jun 2012 13:51:49 -0700 (PDT) Sender: alexandrsergeyev@gmail.com Received: by 10.216.49.16 with HTTP; Mon, 11 Jun 2012 13:51:49 -0700 (PDT) In-Reply-To: <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> Date: Mon, 11 Jun 2012 16:51:49 -0400 X-Google-Sender-Auth: 0mCt6e2HnImpiSauN0v9OxJKgH8 Message-ID: From: Alex Sergeyev To: Ning Kong , weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 20:51:51 -0000 Hi Ning and list members, I hoped to participate in discussion about this proposal for few days but I guess I should be one to say at least something first :) First, to answer your questions: > 1) As for the naming of the terms, should we try to follow the EPP > specs or just use some more self-descriptive and unified terms? For ex= ample, > "roid" or "domainID" for naming the ID of domain object, which one is > better? This is my very personal opinion, I don't see the "ROID" as "domainID". There is just one domain-id and it's "domain name". For the generalization of info that you can get from WEIRDS, it could be called "local-id" some other way. I'm not a big fan of "roid" as a key (and I like local because it's applicable for my other info services that I'm putting together as an experiment, some of them clearly have some sort of "local-id" and others don't) In terms of general "camelCaseKey" or "dash-separated-key" I have no preference, I think working group should just agree on one or another. > =C2=A0 2) Is the extension interface necessary or not? It sounds too restrictive for a task of "information providing service" to have such "extension" section. I think that there should be some common sense concept: * you must provide certain fields * you can provide more * you should not provide information not directly related to object that you're querying that could be provided separately E.g it's clear for me that if I'd want to provide some info-service about previous ownership of the object, I would not stuff that history to an object itself. I'd make "history-of-xxxxx" and refer to it from object itself. Again, note that I'm trying to stay above "domain whois replacement" here. Same time you don't want to invent "timestamp" object and refer to it from all fields because it's just plain abuse. > Any comments are appreciated. Few more questions/comments then :) 1. You use keys "nameserver" and "contact" for lists of things... Could you comment on reasons for not using plurals? I also wonder what others think on using plain array for contacts rather than associative array with "tech/admin/billing" keys (and plain arrays of contact IDs inside of it). I also wondering why you put it this way { domain:{domainName:.... (and other fields here)}, nameserver:[], contact:[], registrar:{}, extension:{} } and not this way: { domainName:... (and other fields here) nameserver:[], contact:[], registrar:{}, extension:{} } It just makes more sense for me to have some identifying fields at the top level of json, not iside of "domain" sub-structure. 2. Way of referencing related objects Your proposal is different from http://tools.ietf.org/html/draft-newton-et-al-weirds-rir-json-response-01 in order to make links to something related. I don't have clear preference but I like having "uris" section in the end with list of references (as in Newton's proposal) because it gives flexibility of adding links where more info needed later without restructuring the data. 3. I'm not sure about mix of hosts and nameservers in one structure. 4. Anybody else thinks that "clientID" and "createID" (and "updateID" in some cases) should have better names and be linked to parent WEIRDS service to find out about those registrars? -- Alex Sergeyev Sr. Engineer of Dyn Labs From andy@arin.net Mon Jun 11 14:47:06 2012 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 9FD1B11E8083 for ; Mon, 11 Jun 2012 14:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sqhKIENC92N for ; Mon, 11 Jun 2012 14:47:06 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id E91B711E808C for ; Mon, 11 Jun 2012 14:47:05 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 26940164FBE; Mon, 11 Jun 2012 17:47:05 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id B7BD9164FA3; Mon, 11 Jun 2012 17:47:04 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 11 Jun 2012 17:46:52 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.4]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0247.003; Mon, 11 Jun 2012 17:46:58 -0400 From: Andy Newton To: Alex Sergeyev Thread-Topic: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt Thread-Index: AQHNSBu5eOEti5AW1kipglNh7sV/Zw== Date: Mon, 11 Jun 2012 21:46:57 +0000 Message-ID: References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <24E759887CDC3C45A4A353A827271BA0@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 21:47:06 -0000 On Jun 11, 2012, at 4:51 PM, Alex Sergeyev wrote: >> 1) As for the naming of the terms, should we try to follow the EPP >> specs or just use some more self-descriptive and unified terms? For ex= ample, >> "roid" or "domainID" for naming the ID of domain object, which one is >> better? >=20 > This is my very personal opinion, I don't see the "ROID" as > "domainID". There is just one domain-id > and it's "domain name". For the generalization of info that you can > get from WEIRDS, it could be called > "local-id" some other way. I'm not a big fan of "roid" as a key (and I > like local because it's applicable for > my other info services that I'm putting together as an experiment, > some of them clearly have some sort > of "local-id" and others don't) I don't really understand "local-id".=20 But an identifier for a domain registration is not necessarily the same thi= ng as the domain name. Let's say example.com has been registered four separ= ate times, the domain id might change for each registration whereas the dom= ain name would be the same for each registration. -andy= From alexandrsergeyev@gmail.com Mon Jun 11 14:59:43 2012 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 2293521F8440 for ; Mon, 11 Jun 2012 14:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41fTuDRaFkYm for ; Mon, 11 Jun 2012 14:59:42 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBBD21F843E for ; Mon, 11 Jun 2012 14:59:42 -0700 (PDT) Received: by werb13 with SMTP id b13so3639331wer.31 for ; Mon, 11 Jun 2012 14:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=EGKn066MH7PX+pfjMz5XtXWmtUZFIJ30pmUGHWBXcrU=; b=Bv7os0zjM02qTpLzCO1hJp5lryGe8cWCP/iAEwyK55lveqPYXm++kJbHKvLa054PMY XP0yzA09XXs7ijedXjghBRexKrfv84W9PvS++XU4ghI0Q25kSYQ212QwFfIry98vKJR+ FGjcVMvwANWbcT6+7luC96XJcH8NsoXR03N4KU+mfyB0Z9g7xCmHxzA+t/rMrRsARmeU LaOYa6TbdJRqBqvjGy9gM6XxaRsIegrgw9cDS5SXVLpJK09r++i5Ci1jPxiXP2BnNYJ2 1BXpA6T3auf8I52nW+GRKSBI3LFcOD8u4dsHp0y3KLCYXzXkN+woADMgkrCYkt33vkkW muTg== MIME-Version: 1.0 Received: by 10.180.93.99 with SMTP id ct3mr24005730wib.13.1339451981570; Mon, 11 Jun 2012 14:59:41 -0700 (PDT) Sender: alexandrsergeyev@gmail.com Received: by 10.216.49.16 with HTTP; Mon, 11 Jun 2012 14:59:41 -0700 (PDT) In-Reply-To: References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> Date: Mon, 11 Jun 2012 17:59:41 -0400 X-Google-Sender-Auth: b1BLm5sG8egd1ohxokw4poeoDlk Message-ID: From: Alex Sergeyev To: weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 21:59:43 -0000 Andy, others, On Mon, Jun 11, 2012 at 5:46 PM, Andy Newton wrote: > I don't really understand "local-id". > But an identifier for a domain registration is not necessarily the same thing as the > domain name. Let's say example.com has been registered four separate times, > the domain id might change for each registration whereas the domain name would > be the same for each registration. I agree and understand this, I just think that it's not some sort of universal id out there, ROIDs from different registries could be same and essentially it's some sort of "localized identifier" for the object inside of the queried WEIRDS service. I don't really care about name, I'm just saying that "roid" is specific to domain names and folks like more generic term that they can use for other objects (say in ip network registration records for same purpose of tracking same network re-registered to another client, they might choose some sort of generic name) -- Alex. From patrick@vande-walle.eu Mon Jun 11 22:30:56 2012 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 9C39821F856D for ; Mon, 11 Jun 2012 22:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wypOpfEdYzmY for ; Mon, 11 Jun 2012 22:30:55 -0700 (PDT) Received: from lucifer.abilit.eu (lucifer.abilit.eu [85.93.218.208]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0B121F856C for ; Mon, 11 Jun 2012 22:30:54 -0700 (PDT) Received: from mail2.isoc.lu (ISOC.abilit.eu [10.10.13.199]) by lucifer.abilit.eu (Postfix) with ESMTPS id 240DB3408AB for ; Tue, 12 Jun 2012 07:30:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.isoc.lu (Postfix) with ESMTP id 750413016F2 for ; Tue, 12 Jun 2012 07:30:51 +0200 (CEST) Received: from mail2.isoc.lu ([127.0.0.1]) by localhost (mail2.isoc.lu [127.0.0.1]) (maiad, port 10024) with ESMTP id 23861-01 for ; Tue, 12 Jun 2012 07:30:16 +0200 (CEST) Received: from Cioran.vande-walle.eu (34.56-65-87.adsl-dyn.isp.belgacom.be [87.65.56.34]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: patrick@vande-walle.eu) by mail2.isoc.lu (Postfix) with ESMTPSA id ABB083016C8 for ; Tue, 12 Jun 2012 07:30:15 +0200 (CEST) VBR-Info: md=vande-walle.eu; mc=all; mv=dwl.spamhaus.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=vande-walle.eu; s=Sig; t=1339479015; bh=JrkTpGVvmZhn9XGpktSbONE+LOq9rnMNGEl47+rU8yA=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=YleNJDHm7LhO2NvXW8griPeBgkzWeGfdK5Yjrm7BPxxzcl0odBKPUBpHTWkZDzA8I F5i0017T0WIDHYngGtK+zimZWvCbxN+xCUKealCLoowNf7w/71DW6J4WKHHqhozC3K 9Kn6xw8sYFlxA8tvWhoyI7+Q/frxnOn5dxut3uUA= Received: from [127.0.0.1] (localhost [127.0.0.1]) by Cioran.vande-walle.eu (Postfix) with ESMTP id 274EB23F39F for ; Tue, 12 Jun 2012 07:30:11 +0200 (CEST) Message-ID: <4FD6D3E2.5050707@vande-walle.eu> Date: Tue, 12 Jun 2012 07:30:10 +0200 From: Patrick Vande Walle Organization: My own disorganization User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120602 Thunderbird/13.0 MIME-Version: 1.0 To: weirds@ietf.org References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> In-Reply-To: <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.4 (mail2.isoc.lu [0.0.0.0]); Tue, 12 Jun 2012 07:30:15 +0200 (CEST) X-Virus-Scanned: Maia Mailguard 1.0.3 Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: patrick@vande-walle.eu List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 05:30:57 -0000 Thanks for this, Ning. I have some comments regarding 3.3.1. Objects in the Contact Response Say the registry has a policy that does not allow the display of all or part of the contact info to the querying party We could either - not return the corresponding field - return the field name, but with an empty value - return the field name, and a field value that could be either - a text string saying the value cannot be displayed by policy, whose content is up to the registry operator - a return code, sort of like HTTP 401 that would indicate the querying party is not authorized to view that information. As for the fields themselves, it has been pointed out that telefax numbers are of little use these days, and that other channels of communications may be more responsive. Facebook and Twitter come to mind. However, these type of services come and go,. They might be out of fashion by the time the work of this WG gets actually deployed. There should be a mechanism that allows for the extension of the contact information, without requiring an update the corresponding RFCs. Cheers, Patrick Vande Walle On 03/06/12 09:39, Ning Kong wrote: > Hi all, > > This is a 00 draft to describe a response format in JSON for name > registries. This document has been reviewed and improved by the design team. > The following issues are still needed to be further discussed. > 1) As for the naming of the terms, should we try to follow the EPP > specs or just use some more self-descriptive and unified terms? For example, > "roid" or "domainID" for naming the ID of domain object, which one is > better? > 2) Is the extension interface necessary or not? > > Any comments are appreciated. > > Cheers, > Ning > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: Sunday, June 03, 2012 3:12 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-kong-dnrd-ap-response-json-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Domain Name Registration Data Access Protocol > Response Format defined in JSON > Author(s) : Ning Kong > Linlin Zhou > Jiagui Xie > Sean Shen > Filename : draft-kong-dnrd-ap-response-json-00.txt > Pages : 21 > Date : 2012-06-03 > > This document describes a response format for registration data > (Whois data) through RESTful Web-based Service. This response format > is defined in JavaScript Object Notation (JSON). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kong-dnrd-ap-response-json-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-kong-dnrd-ap-response-json-00.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-kong-dnrd-ap-response-json/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From nkong@cnnic.cn Tue Jun 12 02:25:22 2012 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 E417121F8534 for ; Tue, 12 Jun 2012 02:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hn7kmJE2B50 for ; Tue, 12 Jun 2012 02:25:22 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id B0F6121F850F for ; Tue, 12 Jun 2012 02:25:21 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Jun 2012 17:25:15 +0800 From: "Ning Kong" To: "'Alex Sergeyev'" , References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> In-Reply-To: Date: Tue, 12 Jun 2012 17:25:09 +0800 Message-ID: <00db01cd487d$44108e60$cc31ab20$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJi3VEHK9xKwykB9g8h5PS1Ivn8igLGgAXPAZBU5tiVp/9pgA== Content-Language: zh-cn Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 09:25:23 -0000 Hi Alex, Thanks for your comments. Please see my feedback inline. > This is my very personal opinion, I don't see the "ROID" as = "domainID". There > is just one domain-id and it's "domain name". For the generalization = of info > that you can get from WEIRDS, it could be called "local-id" some other = way. > I'm not a big fan of "roid" as a key (and I like local because it's = applicable for > my other info services that I'm putting together as an experiment, = some of > them clearly have some sort of "local-id" and others don't) I think there is something opaque in our definition of ROID. The = definition might be modified as the following. roid -- the identifier assigned to the domain name when the object was = created in the repository by a registry. So I agree with you that this ID (roid or domainID or other better name) = should be local. > It sounds too restrictive for a task of "information providing = service" to have > such "extension" section. I think that there should be some common = sense > concept: > * you must provide certain fields In this version, we don't point out which fields are mandatory. I think = it will take some time and energy for us to make sure the certain = fields. If possible, I'd like to contribute on this work and = correspondingly update the following version. > * you can provide more Agree. So we propose the extension interface in this document. I'd like = to know whether you don't like to provide more info in the special = extension section. > * you should not provide information not directly related to object = that > you're querying that could be provided separately We try to follow this rule. See the contact objects in the domain name = response. > 1. You use keys "nameserver" and "contact" for lists of things... > Could you comment on reasons for not using plurals? I think using plurals is better. > I also wonder what others think on using plain array for contacts = rather than > associative array with "tech/admin/billing" > keys (and plain arrays of contact IDs inside of it). So you prefer the following design? "contact": { =E2=80=9Ctech=E2=80=9D: { "contactID": "xyz", "contactUri": "http://example.com/dnrd-ap/contact/xyz/" }, =E2=80=9Cadmin=E2=80=9D: { "contactID": "xyz", "contactUri": "http://example.com/dnrd-ap/contact/xyz/" }, =E2=80=9Cbilling=E2=80=9D: { "contactID": "xyz", "contactUri": "http://example.com/dnrd-ap/contact/xyz/" } } I can't tell which design is better. I think both of them are = acceptable, whether from development aspect or drafting aspect. More = comments are appreciated. > I also wondering why you put it this way { > domain:{domainName:.... (and other fields here)}, > nameserver:[], > contact:[], > registrar:{}, > extension:{} > } >=20 > and not this way: > { > domainName:... > (and other fields here) > nameserver:[], > contact:[], > registrar:{}, > extension:{} > } >=20 > It just makes more sense for me to have some identifying fields at the = top > level of json, not iside of "domain" sub-structure. Your suggestion seems more reasonable. The intent of our design is we'd = like to separate the basic info of a domain from its other related = sections, especially the extension section. By this design, it's easy to = let the user only acquire the basic info of a domain. E.g. = http://example.com/dnrd-ap/example.com/domain I'd like to get more comments on this point. > 2. Way of referencing related objects >=20 > Your proposal is different from > = http://tools.ietf.org/html/draft-newton-et-al-weirds-rir-json-response-01= > in order > to make links to something related. >=20 > I don't have clear preference but I like having "uris" section in the = end with > list of references (as in Newton's proposal) because it gives = flexibility of > adding links where more info needed later without restructuring the = data. I don't think our design is less flexible than the one you mentioned = above. > 3. I'm not sure about mix of hosts and nameservers in one structure. Me either. I think separating them into two objects may be better. Any = more comments? > 4. Anybody else thinks that "clientID" and "createID" (and "updateID" > in some cases) should have better names and be > linked to parent WEIRDS service to find out about those = registrars? We use these names according to the EPP specs. We'd like to accept = better names in future if we can get consensus. Cheers, Ning From patrick@vande-walle.eu Tue Jun 12 05:46:42 2012 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 74A8321F8554 for ; Tue, 12 Jun 2012 05:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 L4rGzKbzGkRd for ; Tue, 12 Jun 2012 05:46:41 -0700 (PDT) Received: from lucifer.abilit.eu (lucifer.abilit.eu [85.93.218.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47121F8557 for ; Tue, 12 Jun 2012 05:46:41 -0700 (PDT) Received: from mail2.isoc.lu (ISOC.abilit.eu [10.10.13.199]) by lucifer.abilit.eu (Postfix) with ESMTPS id 462753401AF for ; Tue, 12 Jun 2012 14:46:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.isoc.lu (Postfix) with ESMTP id 092DB300887 for ; Tue, 12 Jun 2012 14:46:38 +0200 (CEST) Received: from mail2.isoc.lu ([127.0.0.1]) by localhost (mail2.isoc.lu [127.0.0.1]) (maiad, port 10024) with ESMTP id 17353-04 for ; Tue, 12 Jun 2012 14:46:16 +0200 (CEST) Received: from Cioran.vande-walle.eu (unknown [147.67.4.98]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: patrick@vande-walle.eu) by mail2.isoc.lu (Postfix) with ESMTPSA id CA8683007FF for ; Tue, 12 Jun 2012 14:46:15 +0200 (CEST) VBR-Info: md=vande-walle.eu; mc=all; mv=dwl.spamhaus.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=vande-walle.eu; s=Sig; t=1339505175; bh=miFZ2/LcrtTDJvkMXHWwTx44EjCN6c5I/cS1XKokxp4=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=fWoiAvAuZ5zy9T6+8eECFDZapY9+rX07Fr9hd3Ketiw8/jsC1K9OaytKBw5TPJKfA Cu/CIhbtU43pyAB7YbOg4/ZekP/lCEypDMFJuXmvemPEFXtGkcLSKT2kyG80l2kxEE 205sXze2GPUrXCUJ4KluKF1TvEHJgVcFaT1rtv70= Received: from [127.0.0.1] (localhost [127.0.0.1]) by Cioran.vande-walle.eu (Postfix) with ESMTP id 851C5245EFD for ; Tue, 12 Jun 2012 14:46:13 +0200 (CEST) Message-ID: <4FD73A15.20701@vande-walle.eu> Date: Tue, 12 Jun 2012 14:46:13 +0200 From: Patrick Vande Walle Organization: My own disorganization User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120602 Thunderbird/13.0 MIME-Version: 1.0 To: "weirds@ietf.org" References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: multipart/alternative; boundary="------------000200010801020908080708" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.4 (mail2.isoc.lu [0.0.0.0]); Tue, 12 Jun 2012 14:46:15 +0200 (CEST) X-Virus-Scanned: Maia Mailguard 1.0.3 Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: patrick@vande-walle.eu List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 12:46:42 -0000 This is a multi-part message in MIME format. --------------000200010801020908080708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/06/12 13:31, Bob Bruen wrote: > While this does not detract from your point, and this is not a > technical issue, the example of a registry/registrar having a policy > of not displaying all or part of a whois record is not acceptable. The > complete record should always be available. Hi Bob, My point is that we design a system that needs to be used by more than just the registries/registrars that are under contract with ICANN, under their current contractual obligations. If this is acceptable or not is a matter of policy, which is not the goal of this WG. Hence, the end product needs to be flexible enough to address all possible uses, including the legal requirements that can be put on registries and registrars. What this WG produces should not have a bias towards one policy or another. BTW, this is also reflected in ICANN's RFP for an open source implementation : http://www.icann.org/en/news/rfps/restful-whois-16may12-en.pdf (#2.5) Patrick --------------000200010801020908080708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/06/12 13:31, Bob Bruen wrote:
While this does not detract from your point, and this is not a technical issue, the example of a registry/registrar having a policy of not displaying all or part of a whois record is not acceptable. The complete record should always be available.

Hi Bob,

My point is that we design a system that needs to be used by more than just the registries/registrars  that are under contract with ICANN, under their current contractual obligations.   If this is acceptable or not is a matter of policy, which is not the goal of this WG. 

Hence, the end product needs to be flexible enough to address all possible uses,  including the legal requirements that can be put on registries and registrars.  What this WG produces should not have a bias towards one policy or another.  BTW, this is also reflected in ICANN's RFP for an open source implementation :  http://www.icann.org/en/news/rfps/restful-whois-16may12-en.pdf  (#2.5)

Patrick
--------------000200010801020908080708-- From nkong@cnnic.cn Tue Jun 12 05:48:15 2012 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 1850821F857A for ; Tue, 12 Jun 2012 05:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9feTaycHYth for ; Tue, 12 Jun 2012 05:48:14 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id D569B21F8568 for ; Tue, 12 Jun 2012 05:48:13 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Jun 2012 20:48:10 +0800 From: "Ning Kong" To: , References: <4FD63DB0.3030601@zylog.ca> In-Reply-To: <4FD63DB0.3030601@zylog.ca> Date: Tue, 12 Jun 2012 20:48:04 +0800 Message-ID: <00e801cd4899$9c272660$d4757320$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHI2aB9juNnqp8G2QWuKCtcH3HFBJb/f5Yw Content-Language: zh-cn Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt (an a test) 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, 12 Jun 2012 12:48:15 -0000 Hi David, > As to terms, I find the more self-describing the better, so "roid" sounds > undesirable *unless* it's a really well-known term of art. Thanks for your feedback. > This is also a test to see if the list is down or just quiet (;-)) :-) Looking forward to your more comments. Cheers, Ning From nkong@cnnic.cn Tue Jun 12 07:05:19 2012 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 DBD9F21F85F6 for ; Tue, 12 Jun 2012 07:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfXHC89NOuNM for ; Tue, 12 Jun 2012 07:05:18 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 92B4321F85E7 for ; Tue, 12 Jun 2012 07:05:17 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 12 Jun 2012 22:05:01 +0800 From: "Ning Kong" To: , References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> In-Reply-To: <4FD6D3E2.5050707@vande-walle.eu> Date: Tue, 12 Jun 2012 22:04:55 +0800 Message-ID: <00ef01cd48a4$58b44ce0$0a1ce6a0$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJi3VEHK9xKwykB9g8h5PS1Ivn8igLGgAXPApnPps+VoD44oA== Content-Language: zh-cn Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:05:19 -0000 Hi Patrick, > Thanks for this, Ning. My pleasure. > I have some comments regarding 3.3.1. Objects in the Contact Response > > Say the registry has a policy that does not allow the display of all or part of > the contact info to the querying party We could either > > - not return the corresponding field > - return the field name, but with an empty value > - return the field name, and a field value that could be either > - a text string saying the value cannot be displayed by policy, > whose content is up to the registry operator > - a return code, sort of like HTTP 401 that would indicate the > querying party is not authorized to view that information. I think you put forward a general issue. IMO, the HTTP draft (draft-designteam-weirds-using-http-00) as the common infrastructure document is suitable to cover this point. For example, a new section (e.g. 5.5 Unauthorized Answers) may be added to propose the corresponding response mechanisms. BTW, I think another optional response which might also be considered for this scenario is that returning not only the field name and a text saying the querying party is not authorized, but also a reference to tell the requester how to acquire the authorized answers. Through this reference, if the requester can meet the corresponding requirements (e.g. providing correct authentication info or a token authorized by the owner), he/she can further acquire the authorized answers. To consider this kind of response, the authentication mechanism of RESTful WHOIS services needs to be correspondingly designed. > As for the fields themselves, it has been pointed out that telefax numbers are > of little use these days, and that other channels of communications may be > more responsive. Facebook and Twitter come to mind. However, these > type of services come and go,. They might be out of fashion by the time the > work of this WG gets actually deployed. So, I wonder whether we should consider discarding some traditional WHOIS data elements or adopting some new fashionable ones (e.g. IM, SNS) as basic fields. > There should be a mechanism that allows for the extension of the contact > information, without requiring an update the corresponding RFCs. We have the extension interface in the draft. Do you think this can meet the above requirement? Cheers, Ning From ajs@anvilwalrusden.com Tue Jun 12 07:29:33 2012 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 DD38B21F8637 for ; Tue, 12 Jun 2012 07:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 WbLxvHZmdG46 for ; Tue, 12 Jun 2012 07:29:33 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 67EDE21F8552 for ; Tue, 12 Jun 2012 07:29:33 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BC6071ECB41C for ; Tue, 12 Jun 2012 14:29:32 +0000 (UTC) Date: Tue, 12 Jun 2012 10:29:31 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612142931.GE16548@mail.yitter.info> References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD6D3E2.5050707@vande-walle.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:29:34 -0000 On Tue, Jun 12, 2012 at 07:30:10AM +0200, Patrick Vande Walle wrote: > - return the field name, and a field value that could be either > - a text string saying the value cannot be displayed by policy, > whose content is up to the registry operator Please, not this. The whole point of WEIRDS is that it's supposed to be _machine parsable_. Putting magic strings in the answer doesn't qualify. If we're going to do that, we might as well just do whois-bis, put it on port 48043, explicitly state that everything UTF-8, and stop work. > As for the fields themselves, it has been pointed out that telefax > numbers are of little use these days, and that other channels of > communications may be more responsive. Maybe contact information should follow vCard? (*ducks*) A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Jun 12 07:42:26 2012 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 4F24A21F854C for ; Tue, 12 Jun 2012 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 j7tDTTqikS2P for ; Tue, 12 Jun 2012 07:42:25 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CB3D121F8528 for ; Tue, 12 Jun 2012 07:42:25 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 1C74D1ECB41C for ; Tue, 12 Jun 2012 14:42:25 +0000 (UTC) Date: Tue, 12 Jun 2012 10:42:23 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612144223.GF16548@mail.yitter.info> References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> <00ef01cd48a4$58b44ce0$0a1ce6a0$@cnnic.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ef01cd48a4$58b44ce0$0a1ce6a0$@cnnic.cn> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 14:42:26 -0000 On Tue, Jun 12, 2012 at 10:04:55PM +0800, Ning Kong wrote: > I think you put forward a general issue. IMO, the HTTP draft > (draft-designteam-weirds-using-http-00) as the common infrastructure > document is suitable to cover this point. For example, a new section (e.g. > 5.5 Unauthorized Answers) may be added to propose the corresponding response > mechanisms. This raises an interesting and vexing issue, I think. As we're working now, we are talking about responses and requests. But in a REST context, it seems to me, you either get the resource or you don't. One of the goals so far has been to permit differential levels of service depending on credentials. (I believe quite strongly that if we do not provide that functionality, we will have completely botched this work.) It seems to me therefore that data we return must be much more linked and much less cohesive. For instance, in the present draft, the response for domains includes contact data, nameserver data, and so on. But instead, that all ought to be linked data, so that it is possible to return the appropriate response (e.g. the data vs. http 401 or 403 errors) depending on who asks for it. It seems also that it might be possible to create a roll-up type resource that provides all the answers in one go, at the cost of authorization being the denied if any of the underlying resource permissions aren't available. Thoughts? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From andy@arin.net Tue Jun 12 08:02:48 2012 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 65BF821F8471 for ; Tue, 12 Jun 2012 08:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jUJxxTC4QpJ for ; Tue, 12 Jun 2012 08:02:48 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id AE6FE21F8445 for ; Tue, 12 Jun 2012 08:02:47 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 5A38D16501B; Tue, 12 Jun 2012 11:02:46 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id E31A116500B; Tue, 12 Jun 2012 11:02:45 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 12 Jun 2012 11:02:08 -0400 Received: from [10.1.0.49] (10.1.0.49) by CHAXCH03.corp.arin.net (10.1.30.23) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 12 Jun 2012 11:02:45 -0400 Message-ID: <4FD75A15.60404@arin.net> Date: Tue, 12 Jun 2012 11:02:45 -0400 From: Andy Newton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> <00ef01cd48a4$58b44ce0$0a1ce6a0$@cnnic.cn> <20120612144223.GF16548@mail.yitter.info> In-Reply-To: <20120612144223.GF16548@mail.yitter.info> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.0.49] Cc: weirds@ietf.org Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:02:48 -0000 On 06/12/2012 10:42 AM, Andrew Sullivan wrote: > It seems to me therefore that data we return must be much more linked > and much less cohesive. For instance, in the present draft, the > response for domains includes contact data, nameserver data, and so > on. But instead, that all ought to be linked data, so that it is > possible to return the appropriate response (e.g. the data vs. http > 401 or 403 errors) depending on who asks for it. It seems also that > it might be possible to create a roll-up type resource that provides > all the answers in one go, at the cost of authorization being the > denied if any of the underlying resource permissions aren't available. How did you make that logic jump? Redacting information isn't rocket science. Our experience is that people want all the information in one go. We initially rolled out the service with the data objects separated out, and most people did not like that. The other downside is that a client is gonna send multiple queries regardless. Finally, this seems like a corner case. There has yet to be a single example given on this list of any authorization scheme or needed authentication mechanism. -andy From ajs@anvilwalrusden.com Tue Jun 12 08:56:46 2012 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 5885C21F85B6 for ; Tue, 12 Jun 2012 08:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LevMFMztvba7 for ; Tue, 12 Jun 2012 08:56:45 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8421F85B8 for ; Tue, 12 Jun 2012 08:56:45 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 393071ECB41C for ; Tue, 12 Jun 2012 15:56:45 +0000 (UTC) Date: Tue, 12 Jun 2012 11:56:43 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612155643.GI16548@mail.yitter.info> References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> <00ef01cd48a4$58b44ce0$0a1ce6a0$@cnnic.cn> <20120612144223.GF16548@mail.yitter.info> <4FD75A15.60404@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD75A15.60404@arin.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 15:56:46 -0000 On Tue, Jun 12, 2012 at 11:02:45AM -0400, Andy Newton wrote: > > How did you make that logic jump? Redacting information isn't rocket > science. I suppose the alternative is to redact information in responses according to the credentials presented. We could use some sort of http header to warn that some data has been redacted because of lack of authentication? > Our experience is that people want all the information in one go. I'm sure this is true. Of course, this is partly because everyone has a large number of tools built around the assumptions of WHOIS. I think our hope is to offer something better, right? > Finally, this seems like a corner case. There has yet to be a single > example given on this list of any authorization scheme or needed > authentication mechanism. That's not true. First, Murray and John have both said that they'd be entirely willing to trade away the accessibility of contact information for authenticated confirmation that two resources (e.g. two names or two netblocks) are related according to some criteria. I've heard law enforcement people say the same thing, so I'm sure it's valuable. Second, we know that name registrants frequently futz with their contact data in a bid to protect their personally identifying information from being completely and trivially public. Addressing any of these cases is going to require rules about authentication and authorization. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From bob@coldrain.net Tue Jun 12 10:16:19 2012 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 A4CE421F863F for ; Tue, 12 Jun 2012 10:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if35s0goRHEh for ; Tue, 12 Jun 2012 10:16:19 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id E771721F858F for ; Tue, 12 Jun 2012 10:16:18 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5CHGIrU030374 for ; Tue, 12 Jun 2012 13:16:18 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5CHGIOQ030371 for ; Tue, 12 Jun 2012 13:16:18 -0400 Date: Tue, 12 Jun 2012 13:16:18 -0400 (EDT) From: Bob Bruen To: weirds@ietf.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:16:19 -0000 Hi Andrew, IMHO, there should not be a different service depending on credentials. The original whois presented all the available data, then the amount was cut back. It should be like the original, so that all the data is available to anyone. --bob On Tue, 12 Jun 2012, Andrew Sullivan wrote: > On Tue, Jun 12, 2012 at 10:04:55PM +0800, Ning Kong wrote: > >... > One of the goals so far has been to permit differential levels of > service depending on credentials. (I believe quite strongly that if > we do not provide that functionality, we will have completely botched > this work.) >... -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From andy@arin.net Tue Jun 12 10:16:31 2012 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 C169621F8666 for ; Tue, 12 Jun 2012 10:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 iuqXvpcKOpj5 for ; Tue, 12 Jun 2012 10:16:31 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5A821F865F for ; Tue, 12 Jun 2012 10:16:31 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 6F6EA164F4B; Tue, 12 Jun 2012 13:16:30 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id E083B164F45; Tue, 12 Jun 2012 13:16:29 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 12 Jun 2012 13:15:51 -0400 Received: from [10.1.0.49] (10.1.0.49) by CHAXCH03.corp.arin.net (10.1.30.23) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 12 Jun 2012 13:16:29 -0400 Message-ID: <4FD7796D.60608@arin.net> Date: Tue, 12 Jun 2012 13:16:29 -0400 From: Andy Newton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> <00ef01cd48a4$58b44ce0$0a1ce6a0$@cnnic.cn> <20120612144223.GF16548@mail.yitter.info> <4FD75A15.60404@arin.net> <20120612155643.GI16548@mail.yitter.info> In-Reply-To: <20120612155643.GI16548@mail.yitter.info> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.0.49] Cc: weirds@ietf.org Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:16:31 -0000 On 06/12/2012 11:56 AM, Andrew Sullivan wrote: > On Tue, Jun 12, 2012 at 11:02:45AM -0400, Andy Newton wrote: >> >> How did you make that logic jump? Redacting information isn't rocket >> science. > > I suppose the alternative is to redact information in responses > according to the credentials presented. We could use some sort of > http header to warn that some data has been redacted because of lack > of authentication? That works for me. Suggestions? >> Finally, this seems like a corner case. There has yet to be a single >> example given on this list of any authorization scheme or needed >> authentication mechanism. > > That's not true. First, Murray and John have both said that they'd be > entirely willing to trade away the accessibility of contact > information for authenticated confirmation that two resources > (e.g. two names or two netblocks) are related according to some > criteria. I've heard law enforcement people say the same thing, so > I'm sure it's valuable. Second, we know that name registrants > frequently futz with their contact data in a bid to protect their > personally identifying information from being completely and trivially > public. Addressing any of these cases is going to require rules about > authentication and authorization. I would like to see a concrete example of the first use case as "related" is a fairly subjective term. The second use case I understand and is easy to do with simple redaction. -andy From bob@coldrain.net Tue Jun 12 10:17:11 2012 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 A3F7E21F863F for ; Tue, 12 Jun 2012 10:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3emw2WS4n8e for ; Tue, 12 Jun 2012 10:17:11 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id 04A0821F858F for ; Tue, 12 Jun 2012 10:17:10 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5CHHACT030400 for ; Tue, 12 Jun 2012 13:17:10 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5CHHAol030397 for ; Tue, 12 Jun 2012 13:17:10 -0400 Date: Tue, 12 Jun 2012 13:17:10 -0400 (EDT) From: Bob Bruen To: weirds@ietf.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:17:11 -0000 Hi Andrew, People want the information in one go because they want the information, not just because they have tools. If you want to offer something better, you should not offer less. I am one of those people who use the information in whois (not for marketing or spam). Murray and John and some LE folks may be willing to trade off, but a lot of us are not. I also think there is a difference between individuals and businesses - if you to differentiate a service level, this could be one. --bob On Tue, 12 Jun 2012, Andrew Sullivan wrote: > On Tue, Jun 12, 2012 at 11:02:45AM -0400, Andy Newton wrote: > > > > How did you make that logic jump? Redacting information isn't rocket > > science. > > I suppose the alternative is to redact information in responses > according to the credentials presented. We could use some sort of > http header to warn that some data has been redacted because of lack > of authentication? > > > Our experience is that people want all the information in one go. > > I'm sure this is true. Of course, this is partly because everyone has > a large number of tools built around the assumptions of WHOIS. I > think our hope is to offer something better, right? > > > Finally, this seems like a corner case. There has yet to be a single > > example given on this list of any authorization scheme or needed > > authentication mechanism. > > That's not true. First, Murray and John have both said that they'd be > entirely willing to trade away the accessibility of contact > information for authenticated confirmation that two resources > (e.g. two names or two netblocks) are related according to some > criteria. I've heard law enforcement people say the same thing, so > I'm sure it's valuable. Second, we know that name registrants > frequently futz with their contact data in a bid to protect their > personally identifying information from being completely and trivially > public. Addressing any of these cases is going to require rules about > authentication and authorization. > > Best, > > A > -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From bob@coldrain.net Tue Jun 12 10:18:01 2012 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 4B41B21F865E for ; Tue, 12 Jun 2012 10:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1+55SHQvWWi for ; Tue, 12 Jun 2012 10:18:00 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id 15E6F21F865D for ; Tue, 12 Jun 2012 10:17:59 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5CHHxEV030422 for ; Tue, 12 Jun 2012 13:17:59 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5CHHx1S030419 for ; Tue, 12 Jun 2012 13:17:59 -0400 Date: Tue, 12 Jun 2012 13:17:59 -0400 (EDT) From: Bob Bruen To: weirds@ietf.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:18:01 -0000 Hi Patrick, I understand your point, which is why I stated that my point was not a technical issue. I am concerned that the technical decisions made along the way might have a negative impact on the policy downstream. The current whois is swamp of problems, some technical (like formats), but mostly policy. The ICANN RAA contract is currently unenforcable. Legal requirements for registr[ars|ies] do not exist. I do not want to turn this into a distraction. I just want to see that these things are considered as part of the technical development to limit unintended consequences. If anyone does want to know more details, please contact me directly. --bob On Tue, 12 Jun 2012, Patrick Vande Walle wrote: > On 12/06/12 13:31, Bob Bruen wrote: > > While this does not detract from your point, and this is not a > > technical issue, the example of a registry/registrar having a policy > > of not displaying all or part of a whois record is not acceptable. The > > complete record should always be available. > Hi Bob, > > My point is that we design a system that needs to be used by more than > just the registries/registrars that are under contract with ICANN, > under their current contractual obligations. If this is acceptable or > not is a matter of policy, which is not the goal of this WG. > > Hence, the end product needs to be flexible enough to address all > possible uses, including the legal requirements that can be put on > registries and registrars. What this WG produces should not have a bias > towards one policy or another. BTW, this is also reflected in ICANN's > RFP for an open source implementation : > http://www.icann.org/en/news/rfps/restful-whois-16may12-en.pdf (#2.5) > > Patrick > -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From bob@coldrain.net Tue Jun 12 10:18:27 2012 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 6613A21F866E for ; Tue, 12 Jun 2012 10:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJicsyKc3UV8 for ; Tue, 12 Jun 2012 10:18:27 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id C9B7C21F8668 for ; Tue, 12 Jun 2012 10:18:26 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5CHIQsO030445 for ; Tue, 12 Jun 2012 13:18:26 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5CHIQLj030442 for ; Tue, 12 Jun 2012 13:18:26 -0400 Date: Tue, 12 Jun 2012 13:18:26 -0400 (EDT) From: Bob Bruen To: weirds@ietf.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:18:27 -0000 Hi Andrew, IMHO, there should not be a different service depending on credentials. The original whois presented all the available data, then the amount was cut back. It should be like the original, so that all the data is available to anyone. --bob On Tue, 12 Jun 2012, Andrew Sullivan wrote: > On Tue, Jun 12, 2012 at 10:04:55PM +0800, Ning Kong wrote: > >... > One of the goals so far has been to permit differential levels of > service depending on credentials. (I believe quite strongly that if > we do not provide that functionality, we will have completely botched > this work.) >... -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From ajs@anvilwalrusden.com Tue Jun 12 10:21:53 2012 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 616CC21F8668 for ; Tue, 12 Jun 2012 10:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8ydrVKi1rNgt for ; Tue, 12 Jun 2012 10:21:52 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id AADF421F84B6 for ; Tue, 12 Jun 2012 10:21:52 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7AAE21ECB41C for ; Tue, 12 Jun 2012 17:21:51 +0000 (UTC) Date: Tue, 12 Jun 2012 13:21:46 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612172135.GA25201@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 17:21:53 -0000 Hi, On Tue, Jun 12, 2012 at 01:16:18PM -0400, Bob Bruen wrote: > IMHO, there should not be a different service depending on credentials. As someone has already, I think, said, that is a policy question, and not a protocol question. For what it's worth, I completely disagree. This list is the wrong place to debate why. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From bob@coldrain.net Tue Jun 12 10:41:34 2012 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 8A3B221F8475 for ; Tue, 12 Jun 2012 10:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLBbXz1XGSOm for ; Tue, 12 Jun 2012 10:41:34 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4321F8472 for ; Tue, 12 Jun 2012 10:41:33 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5CHfULr030830 for ; Tue, 12 Jun 2012 13:41:30 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5CHfURD030826 for ; Tue, 12 Jun 2012 13:41:30 -0400 Date: Tue, 12 Jun 2012 13:41:30 -0400 (EDT) From: Bob Bruen To: weirds@ietf.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [weirds] policy & tech 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, 12 Jun 2012 17:41:34 -0000 Hi Andrew, Let me see if I have this correctly: You wrote: > One of the goals so far has been to permit differential levels of > service depending on credentials. (I believe quite strongly that if > we do not provide that functionality, we will have completely botched > this work.) And I responded: > IMHO, there should not be a different service depending on credentials Then you wrote; > As someone has already, I think, said, that is a policy question, and > not a protocol question. For what it's worth, I completely disagree. > This list is the wrong place to debate why. This ends up with you wanting a policy expressed in the protocol and that's okay, but what I said is not okay because I think it should not be. My initial point was to ask that the technical development took into consideration any potential policy outcomes later on. This is an example of that. I do not want this to a debate about policy, but the technical aspects should either be neutral with respect to policy or, if not, then considered carefully. --bob -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From ajs@anvilwalrusden.com Tue Jun 12 11:14:07 2012 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 D7ED121F8628 for ; Tue, 12 Jun 2012 11:14:07 -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 zqFXzcNgW-Ym for ; Tue, 12 Jun 2012 11:14:07 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0821F8630 for ; Tue, 12 Jun 2012 11:14:02 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id D72431ECB41C for ; Tue, 12 Jun 2012 18:14:01 +0000 (UTC) Date: Tue, 12 Jun 2012 14:14:00 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612181400.GB25201@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] policy & tech 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, 12 Jun 2012 18:14:08 -0000 On Tue, Jun 12, 2012 at 01:41:30PM -0400, Bob Bruen wrote: > And I responded: > > >IMHO, there should not be a different service depending on credentials > > Then you wrote; > > >As someone has already, I think, said, that is a policy question, and > >not a protocol question. For what it's worth, I completely disagree. > >This list is the wrong place to debate why. > > This ends up with you wanting a policy expressed in the protocol and > that's okay, but what I said is not okay because I think it should > not be. No, I want the protocol to make _possible_ a policy. It could be that nobody will turn this knob on. If that were to happen, then the protocol would have a needless feature, and that is bad. But I predict that someone will turn that knob on, because a significant chunk of WHOIS complaints come from people who claim that the exposure of all that contact information is in violation of certain national implementations of EU data protection directorates. I have no idea whether that is true, and don't care, because if we have a protocol that supports such policy decisions then we have offered the necessary technical supports. > My initial point was to ask that the technical development took into > consideration any potential policy outcomes later on. This is an > example of that. > > I do not want this to a debate about policy, but the technical > aspects should either be neutral with respect to policy or, if not, > then considered carefully. What you appear to be arguing is that you have a preferred policy outcome, and that therefore the protocol should be written to make sure an alternative isn't possible. If that's what we want, then there is absolutely no reason whatsoever to continue with this work. Let's leave WHOIS in place. There is no reason for us to invent a new way to express exactly the same limitations. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From steve.sheng@icann.org Tue Jun 12 11:39:08 2012 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 D74A621F865F for ; Tue, 12 Jun 2012 11:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 WenAq5HtWVKA for ; Tue, 12 Jun 2012 11:39:06 -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 387C221F8659 for ; Tue, 12 Jun 2012 11:39:06 -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, 12 Jun 2012 11:39:04 -0700 From: Steve Sheng To: Olaf Kolkman , Web Extensible Internet Registration Data Service Working Group Date: Tue, 12 Jun 2012 11:39:00 -0700 Thread-Topic: [weirds] Divide and Conquer Thread-Index: Ac1IyqRwJF+WhTgdQPaJ5QcQWhTRCA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422345940_4757614" MIME-Version: 1.0 Subject: Re: [weirds] Divide and Conquer 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, 12 Jun 2012 18:39:08 -0000 --B_3422345940_4757614 Content-type: multipart/mixed; boundary="B_3422345940_4754044" --B_3422345940_4754044 Content-type: multipart/alternative; boundary="B_3422345940_4800666" --B_3422345940_4800666 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello Olaf and all, From: Olaf Kolkman To: Web Extensible Internet Registration Data Service Working Group Subject: [weirds] Divide and Conquer > > Dear Colleagues, > > Murray and myself have been talking to a few active working participants, with > the area director, and among ourselves. > > Based on those discussion, and after coordination with Murray, I would > like to make two proposals for getting work done: > > > 1. Working group drafts and output documents. > > Murray has already called for adaption of a number of documents. Those > documents are all input documents. The output of the working group > might find its way into a different set of documents. > > A structure that has been proposed to me by Scott H. and Andy N. seems > reasonable: > > 1. For all implementers: > 1.1 The use of HTTP > 1.2 Details of Redirecting > > 1.3 Specification of generic json responses and extensibility mechanism > 1.4 Specification of generic xml responses and extensibility mechanism > > 2.Numbers: > 2.1 specification of queries > 2.2 specification of specific number-responses json responses > > 3.Names: > 3.1 specification of queries > 3.2 specification of specific name-related json responses > and/or > 3.3 specification of specific number-related xml responses > > > It might be that 1.3 and 1.4 are so minimal that the information > therein is better (dublicated) in 2.2, 3.2, and 3.3. > > > > 2. Dealing with the data framework. > > I believe that the data framework for the domain name space is one of > the biggest elephants in the room and that making sure we converge to > a comon understanding is critical to success of the working group. It > seems that an enumeration of all data elements that are comonly in use > including comonly used formats. Ray Bellis and Frederico Neves > have made a start with that in a spreadsheet at > https://docs.google.com/spreadsheet/ccc?key=0AjZQpmBlboLWdFBfdERTQm9QQWdrejNta > TBhNmI3SHc#gid=0 > and it seems that we can use that as a basis. I have done an inventory of the data elements that current gTLD registries' Registration Data Directory Service (RDDS) output. Attached please find the spreadsheet. This inventory contains 159 data elements that are: - actual RDDS output of 18 gTLD registries - new gTLD RDDS output as specified by ICANN applicant guidebook Among these 159 data elements, 75 are common elements, 84 are registry specific elements. This distinction is also highlighted in the excel sheet. Finally, I have also harmonized data labels from different gTLD registries that refer to the same element. Note, the scope of this exercise is limited to domain queries for gTLD registries, it does not cover querying name server and registrars, nor does it cover registrar RDDS in the case of thin registries. If people find this preliminary exercise useful, I can continue to work on this, and also invite others to participate to get this done for gTLDs as well as ccTLDs. Steve > > Once we have a relatively complete enumeration of all data elements > that are commonly in use we continue with trying to get convergence on > their presentation format (it seems we have to do that irrespective of > encaptulation in json or xml). > > One of the important questions that might help to converge while > defining data elements and while determining such data-element can be > queried is whether the query-response protocol is direct match, or > search. The charter is not clear about this, I believe. Hence I > propose that we focus on the low-hanging fruit of direct-match and > that we circumvent any questions of the type 'what type of matching > algorithm to apply?' > > For instance, if we have a person name as a data element then a query > for "Kolkman" might not yield a unique result and some matching > algorithm may need to be applied, the use of a NIC-handle might be > more appropriate in such cases. By agreeing on the principle that we > work towards direct-match we know how to focus our energy. > > How does this sound as a first order approach? If folk like this we'll > try to come up with a way to capture the information in the spreadsheet > (or other appropriate tool) and work forward in a structured way. > > --Olaf > WEIRDS co-chair > > > NLnet > Labs > Olaf M. Kolkman > > www.NLnetLabs.nl > olaf@NLnetLabs.nl > > Science Park 400, 1098 XH Amsterdam, The Netherlands > > > > --B_3422345940_4800666 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello Olaf and all, 

From: Olaf Kolkman <= ;olaf@nlnetlabs.nl>
To: Web Extensible Internet Registration Data Se= rvice Working Group <weirds@ietf.org= >
Subject: [weirds] Divide and = Conquer

<= div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-bre= ak: after-white-space; ">

Dear Colleagues,

Murray = and myself have been talking to a few active working participants, with the = area director, and among ourselves. 

Based on = those discussion, and after coordination with Murray, I would
like= to make two proposals for getting work done:


<= /div>
1. Working group drafts and output documents.

=
Murray has already called for adaption of a number of documents. Those<= /div>
documents are all input documents. The output of the working group=
might find its way into a different set of documents.
<= br>
A structure that has been proposed to me by Scott H. and Andy = N. seems reasonable: 

1. For all implementers:=
  1.1 The use of HTTP
  1.2 Details of Redire= cting

  1.3 Specification of generic json resp= onses and extensibility mechanism
  1.4 Specification of gene= ric xml responses and extensibility mechanism

2.Num= bers:
  2.1 specification of queries
  2.2 spe= cification of specific number-responses json responses

<= div>3.Names:
  3.1 specification of queries
  = 3.2 specification of specific name-related json responses 
an= d/or
  3.3 specification of specific number-related xml respo= nses


It might be that 1.3 and 1.4 ar= e so minimal that the information
therein is better (dublicated) i= n 2.2, 3.2, and 3.3.



= 2. Dealing with the data framework.

I believe that = the data framework for the domain name space is one of
the biggest= elephants in the room and that making sure we converge to
a comon= understanding is critical to success of the working group. It
see= ms that an enumeration of all data elements that are comonly in use
including comonly used formats. Ray Bellis and Frederico Neves
h= ave made a start with that in a spreadsheet at
and it seems that= we can use that as a basis.

I have done an inventory of the data elements th= at current gTLD registries' Registration Data Directory Service (RDDS) outpu= t. 

Attached please find the spreadsheet. = ;This inventory contains 159 data elements that are: 
  = - actual RDDS output of 18 gTLD registries
  - new gTLD RDDS = output as specified by ICANN applicant guidebook 

<= div>Among these 159 data elements, 75 are common elements,  84 are regi= stry specific elements. This distinction is also highlighted in the excel sh= eet. 

Finally, I have also harmonized  da= ta labels from different gTLD registries that refer to the same element. &nb= sp;

Note, the scope of this exercise is limited to = domain queries for gTLD registries, it does not cover querying name server a= nd registrars, nor does it cover registrar RDDS in the case of thin registri= es. If people find this preliminary exercise useful, I can continue to work = on this, and also invite others to participate to get this done for gTLDs as= well as ccTLDs.  

Steve

<= span id=3D"OLK_SRC_BODY_SECTION">

Once we have a relatively complete enumer= ation of all data elements
that are commonly in use we continue wi= th trying to get convergence on
their presentation format (it seem= s we have to do that irrespective of
encaptulation in json or xml)= .

One of the important questions that might help to= converge while
defining data elements and while determining such = data-element can be
queried is whether the query-response protocol= is direct match, or
search. The charter is not clear about this, = I believe. Hence I
propose that we focus on the low-hanging fruit = of direct-match and
that we circumvent any questions of the type '= what type of matching
algorithm to apply?' 

For instance, if we have a person name as a data element then a quer= y
for "Kolkman" might not yield a unique result and some matching<= /div>
algorithm may need to be applied, the use of a NIC-handle might be=
more appropriate in such cases. By agreeing on the principle that= we
work towards direct-match we know how to focus our energy.

How does this sound as a first order approach? If folk= like this we'll
try to come up with a way to capture the informat= ion in the spreadsheet
(or other appropriate tool) and work forwar= d in a structured way.

--Olaf 
 = ; WEIRDS co-chair


<= tr>
NLnet
Labs
= Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The Netherlands
=



--B_3422345940_4800666-- --B_3422345940_4754044 Content-type: application/x-msexcel; name="June 12 gTLD Registry Data Model.xls"; x-mac-creator="5843454C"; x-mac-type="584C5338" Content-disposition: attachment; filename="June 12 gTLD Registry Data Model.xls" Content-transfer-encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAA AAAAEAAAewAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////9////fgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAA AAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA PgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsA AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAA WQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYA AABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAA dAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAP7////+////fQAAAP7////+/////////1IA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAACAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAADF amfJSM0BfAAAAMACAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEEAAAA//////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAqPAAAAAAAAAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEA AAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkAAAA AAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAAAABABAAAAAAAACQgQAAAGBQDNVswHEAADAAYGAADhAAIAsATBAAIA AADiAAAAXABwAAsAAFN0ZXZlIFNoZW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCAAIAsARhAQIAAAA9AQYAAQASABMAnAACABEAGQACAAAAEgACAAAA EwACAAAArwECAAAAvAECAAAAPQASAAAAAACAcAwwOAAAAAAAAQC5AkAAAgAAAI0AAgAAACIA AgABAA4AAgABALcBAgAAANoAAgAAADEAHgDIAAAA/3+QAQAAAAAA9gcBVgBlAHIAZABhAG4A YQAxAB4AyAABAP9/vAIAAAAAAPYHAVYAZQByAGQAYQBuAGEAMQAeAMgAAgD/f5ABAAAAAAD2 BwFWAGUAcgBkAGEAbgBhADEAHgDIAAMA/3+8AgAAAAAA9gcBVgBlAHIAZABhAG4AYQAxAB4A yAAAAP9/kAEAAAAAAPYHAVYAZQByAGQAYQBuAGEAMQAeAKAAAAD/f5ABAAAAAAD2BwFWAGUA cgBkAGEAbgBhADEAHgDIAAQADACQAQAAAQAA9gcBVgBlAHIAZABhAG4AYQAxAB4AyAAEAD0A kAEAAAEAAPYHAVYAZQByAGQAYQBuAGEAMQAeABgBAQD/f7wCAAAAAAD2BwFWAGUAcgBkAGEA bgBhADEAHgDwAAEA/3+8AgAAAAAA9gcBVgBlAHIAZABhAG4AYQAxAB4A8AAAAP9/kAEAAAAA APYHAVYAZQByAGQAYQBuAGEAMQAeABgBAAD/f5ABAAAAAAD2BwFWAGUAcgBkAGEAbgBhADEA HgAEAQEA/3+8AgAAAAAA9gcBQwBhAGwAaQBiAHIAaQAxAB4A8AAAAAgAkAEAAAACAPYHAUMA YQBsAGkAYgByAGkAMQAeAPAAAAAJAJABAAAAAgD2BwFDAGEAbABpAGIAcgBpADEAHgDwAAAA DgCQAQAAAAIAAAcBQwBhAGwAaQBiAHIAaQAxAB4A8AABADQAvAIAAAACAAAHAUMAYQBsAGkA YgByAGkAMQAeAPAAAQAJALwCAAAAAgAABwFDAGEAbABpAGIAcgBpADEAHgDwAAIAFwCQAQAA AAIAAAcBQwBhAGwAaQBiAHIAaQAxAB4A8AAAABEAkAEAAAACAAAHAUMAYQBsAGkAYgByAGkA MQAeACwBAQA+ALwCAAAAAgAABwFDAGEAbABpAGIAcgBpADEAHgAEAQEAPgC8AgAAAAIAAAcB QwBhAGwAaQBiAHIAaQAxAB4A3AABAD4AvAIAAAACAAAHAUMAYQBsAGkAYgByAGkAMQAeAPAA AAA+AJABAAAAAgAABwFDAGEAbABpAGIAcgBpADEAHgDwAAAANACQAQAAAAIAAAcBQwBhAGwA aQBiAHIAaQAxAB4A8AAAADwAkAEAAAACAAAHAUMAYQBsAGkAYgByAGkAMQAeAPAAAQA/ALwC AAAAAgAABwFDAGEAbABpAGIAcgBpADEAHgBoAQEAPgC8AgAAAAIAAAcBQwBhAG0AYgByAGkA YQAxAB4A8AABAAgAvAIAAAACAAAHAUMAYQBsAGkAYgByAGkAMQAeAPAAAAAKAJABAAAAAgAA BwFDAGEAbABpAGIAcgBpADEAHgDIAAAACACQAQAAAAAAAAcBVgBlAHIAZABhAG4AYQAxAB4A BAEBAAgAvAIAAAACAAAHAUMAYQBsAGkAYgByAGkAHgQcAAUAFwAAIiQiIywjIzBfKTtcKCIk IiMsIyMwXCkeBCEABgAcAAAiJCIjLCMjMF8pO1tSZWRdXCgiJCIjLCMjMFwpHgQiAAcAHQAA IiQiIywjIzAuMDBfKTtcKCIkIiMsIyMwLjAwXCkeBCcACAAiAAAiJCIjLCMjMC4wMF8pO1tS ZWRdXCgiJCIjLCMjMC4wMFwpHgQ3ACoAMgAAXygiJCIqICMsIyMwXyk7XygiJCIqIFwoIywj IzBcKTtfKCIkIiogIi0iXyk7XyhAXykeBC4AKQApAABfKCogIywjIzBfKTtfKCogXCgjLCMj MFwpO18oKiAiLSJfKTtfKEBfKR4EPwAsADoAAF8oIiQiKiAjLCMjMC4wMF8pO18oIiQiKiBc KCMsIyMwLjAwXCk7XygiJCIqICItIj8/Xyk7XyhAXykeBDYAKwAxAABfKCogIywjIzAuMDBf KTtfKCogXCgjLCMjMC4wMFwpO18oKiAiLSI/P18pO18oQF8p4AAUAAAAAAD1/yAAAAAAAAAA AAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAABACAAAAAAAAAAAAAAAMAg4AAUAA4AAAD1/yAA ALQAAAAAAAAABIkg4AAUAA4AAAD1/yAAALQAAAAAAAAABK8g4AAUAA4AAAD1/yAAALQAAAAA AAAABJog4AAUAA4AAAD1/yAAALQAAAAAAAAABIkg4AAUAA4AAAD1/yAAALQAAAAAAAAABJsg 4AAUAA4AAAD1/yAAALQAAAAAAAAABK8g4AAUAA4AAAD1/yAAALQAAAAAAAAABJYg4AAUAA4A AAD1/yAAALQAAAAAAAAABJ0g4AAUAA4AAAD1/yAAALQAAAAAAAAABKsg4AAUAA4AAAD1/yAA ALQAAAAAAAAABJYg4AAUAA4AAAD1/yAAALQAAAAAAAAABKwg4AAUAA4AAAD1/yAAALQAAAAA AAAABK8g4AAUAA8AAAD1/yAAALQAAAAAAAAABLEg4AAUAA8AAAD1/yAAALQAAAAAAAAABJ0g 4AAUAA8AAAD1/yAAALQAAAAAAAAABKsg4AAUAA8AAAD1/yAAALQAAAAAAAAABJYg4AAUAA8A AAD1/yAAALQAAAAAAAAABLEg4AAUAA8AAAD1/yAAALQAAAAAAAAABK8g4AAUAA8AAAD1/yAA ALQAAAAAAAAABLEg4AAUAA8AAAD1/yAAALQAAAAAAAAABJMg4AAUAA8AAAD1/yAAALQAAAAA AAAABJMg4AAUAA8AAAD1/yAAALQAAAAAAAAABLYg4AAUAA8AAAD1/yAAALQAAAAAAAAABLEg 4AAUAA8AAAD1/yAAALQAAAAAAAAABLUg4AAUABAAAAD1/yAAALQAAAAAAAAABK0g4AAUABEA AAD1/yAAAJQREZcLlwsABIkg4AAUABIAAAD1/yAAAJRmZr8fvx8ABLcg4AAUAAUAKwD1/yAA APgAAAAAAAAAAMAg4AAUAAUAKQD1/yAAAPgAAAAAAAAAAMAg4AAUAAUALAD1/yAAAPgAAAAA AAAAAMAg4AAUAAUAKgD1/yAAAPgAAAAAAAAAAMAg4AAUABMAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAgAAAD0/wAAAPQAAAAAAAAAAMAg4AAUABQAAAD1/yAAALQAAAAAAAAABKog4AAUABUA AAD1/yAAANQAUAAAgBgAAMAg4AAUABYAAAD1/yAAANQAUAAAAAsAAMAg4AAUABcAAAD1/yAA ANQAIAAAgBgAAMAg4AAUABcAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAcAAAD0/wAAAPQAAAAA AAAAAMAg4AAUABgAAAD1/yAAAJQREZcLlwsABK8g4AAUABkAAAD1/yAAANQAYAAAABoAAMAg 4AAUABoAAAD1/yAAALQAAAAAAAAABKsg4AAUAAUAAAD1/yAAAJwRERYLFgsABJog4AAUABsA AAD1/yAAAJQREb8fvx8ABIkg4AAUAAUACQD1/yAAAPgAAAAAAAAAAMAg4AAUABwAAAD1/yAA APQAAAAAAAAAAMAg4AAUAB0AAAD1/yAAANQAYQAAsRgAAMAg4AAUAB4AAAD1/yAAAPQAAAAA AAAAAMAg4AAUAAkAAAABACAAAGgREUAgQCAAAMAg4AAUAAAAAAABACAAAGgREUAgQCAAAMAg 4AAUAAoAAAABACAAAGgREUAgQCAAAMAg4AAUAAAAAAABACAAACAREUAgQCAAAMAg4AAUAAAA AAABACAAACARAUAgQAAAAMAg4AAUAAAAAAABACAAAHgREUAgQCAAAMAg4AAUAAAAAAABACAA ACAREEAgACAAAMAg4AAUAAsAAAABACAAAGgREUAgQCAAAMAg4AAUAAAAAAABACgAAHgREUAg QCAAAMAg4AAUAAAAAAABABgAAHgREUAgQCAAAMAg4AAUAAEAAAABABgAAHgREUAgQCAAAMAg 4AAUAB8AAAABACAAAAgAAAAAAAAAAsAg4AAUAAwAAAABACAAAAgAAAAAAAAAAMAg4AAUAAEA AAABACAAAAgAAAAAAAAAAMAg4AAUAAEAAwABACAAAAwAAAAAAAAAAMAg4AAUACAAAwABACAA AAwAAAAAAAAAAsAg4AAUAA0AAwABACAAAAwAAAAAAAAAAMAg4AAUAA0AAwABACAAAGwREUAg QCAAAMAg4AAUAAwAAAABACAAAGgAAAAAAAAAAMAg4AAUAAkAAAABACEAAHgREUAgQCAAAMAg fAgUAHwIAAAAAAAAAAAAAAAAVAB9lpRefQhBAH0IAAAAAAAAAAAAAAAAEAAAAAMADQAUAAMA AAABAAAAMDBcKTtfKCoOAAUAAgQAFAADAGVmBAAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAA AAAAEQAAAAMADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAgQAFAADAGVmBQAAADtfKEBfKSAg fQhBAH0IAAAAAAAAAAAAAAAAEgAAAAMADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAgQAFAAD AGVmBgAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAEwAAAAMADQAUAAMAAAABAAAAMDBc KTtfKCoOAAUAAgQAFAADAGVmBwAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAFAAAAAMA DQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAgQAFAADAGVmCAAAADtfKEBfKSAgfQhBAH0IAAAA AAAAAAAAAAAAFQAAAAMADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAgQAFAADAGVmCQAAADtf KEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAFgAAAAMADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUA AgQAFAADAMxMBAAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAFwAAAAMADQAUAAMAAAAB AAAAMDBcKTtfKCoOAAUAAgQAFAADAMxMBQAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAA GAAAAAMADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAgQAFAADAMxMBgAAADtfKEBfKSAgfQhB AH0IAAAAAAAAAAAAAAAAGQAAAAMADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAgQAFAADAMxM BwAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAGgAAAAMADQAUAAMAAAABAAAAMDBcKTtf KCoOAAUAAgQAFAADAMxMCAAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAGwAAAAMADQAU AAMAAAABAAAAMDBcKTtfKCoOAAUAAgQAFAADAMxMCQAAADtfKEBfKSAgfQhBAH0IAAAAAAAA AAAAAAAAHAAAAAMADQAUAAMAAAAAAAAAMDBcKTtfKCoOAAUAAgQAFAADADIzBAAAADtfKEBf KSAgfQhBAH0IAAAAAAAAAAAAAAAAHQAAAAMADQAUAAMAAAAAAAAAMDBcKTtfKCoOAAUAAgQA FAADADIzBQAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAHgAAAAMADQAUAAMAAAAAAAAA MDBcKTtfKCoOAAUAAgQAFAADADIzBgAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAHwAA AAMADQAUAAMAAAAAAAAAMDBcKTtfKCoOAAUAAgQAFAADADIzBwAAADtfKEBfKSAgfQhBAH0I AAAAAAAAAAAAAAAAIAAAAAMADQAUAAMAAAAAAAAAMDBcKTtfKCoOAAUAAgQAFAADADIzCAAA ADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAIQAAAAMADQAUAAMAAAAAAAAAMDBcKTtfKCoO AAUAAgQAFAADADIzCQAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAIgAAAAMADQAUAAMA AAAAAAAAMDBcKTtfKCoOAAUAAgQAFAADAAAABAAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAA AAAAIwAAAAMADQAUAAMAAAAAAAAAMDBcKTtfKCoOAAUAAgQAFAADAAAABQAAADtfKEBfKSAg fQhBAH0IAAAAAAAAAAAAAAAAJAAAAAMADQAUAAMAAAAAAAAAMDBcKTtfKCoOAAUAAgQAFAAD AAAABgAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAJQAAAAMADQAUAAMAAAAAAAAAMDBc KTtfKCoOAAUAAgQAFAADAAAABwAAADtfKEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAJgAAAAMA DQAUAAMAAAAAAAAAMDBcKTtfKCoOAAUAAgQAFAADAAAACAAAADtfKEBfKSAgfQhBAH0IAAAA AAAAAAAAAAAAJwAAAAMADQAUAAMAAAAAAAAAMDBcKTtfKCoOAAUAAgQAFAADAAAACQAAADtf KEBfKSAgfQhBAH0IAAAAAAAAAAAAAAAAKAAAAAMADQAUAAIAAACcAAb/MDBcKTtfKCoOAAUA AgQAFAACAAAA/8fO/ztfKEBfKSAgfQiRAH0IAAAAAAAAAAAAAAAAKQAAAAcADQAUAAIAAAD6 fQD/MDBcKTtfKCoOAAUAAgQAFAACAAAA8vLy/ztfKEBfKSAgBwAUAAIAAAB/f3//ICAgICAg ICAIABQAAgAAAH9/f/8gICAgICAgIAkAFAACAAAAf39///gLwGAAC8AACgAUAAIAAAB/f3// AAAAAAAAAAB9CJEAfQgAAAAAAAAAAAAAAAAqAAAABwANABQAAwAAAAAAAAAwMFwpO18oKg4A BQACBAAUAAIAAAClpaX/O18oQF8pICAHABQAAgAAAD8/P/8gICAgICAgIAgAFAACAAAAPz8/ /yAgICAgICAgCQAUAAIAAAA/Pz//+AvAYAALwAAKABQAAgAAAD8/P/8AAAAAAAAAAH0ILQB9 CAAAAAAAAAAAAAAAAC8AAAACAA0AFAACAAAAf39//zAwXCk7XygqDgAFAAJ9CEEAfQgAAAAA AAAAAAAAAAAxAAAAAwANABQAAgAAAABhAP8wMFwpO18oKg4ABQACBAAUAAIAAADG787/O18o QF8pICB9CEEAfQgAAAAAAAAAAAAAAAAyAAAAAwANABQAAwAAAAMAAAAwMFwpO18oKg4ABQAC CAAUAAMAAAAEAAAAO18oQF8pICB9CEEAfQgAAAAAAAAAAAAAAAAzAAAAAwANABQAAwAAAAMA AAAwMFwpO18oKg4ABQACCAAUAAMA/z8EAAAAO18oQF8pICB9CEEAfQgAAAAAAAAAAAAAAAA0 AAAAAwANABQAAwAAAAMAAAAwMFwpO18oKg4ABQACCAAUAAMAMjMEAAAAO18oQF8pICB9CC0A fQgAAAAAAAAAAAAAAAA1AAAAAgANABQAAwAAAAMAAAAwMFwpO18oKg4ABQACfQiRAH0IAAAA AAAAAAAAAAAANwAAAAcADQAUAAIAAAA/P3b/MDBcKTtfKCoOAAUAAgQAFAACAAAA/8yZ/ztf KEBfKSAgBwAUAAIAAAB/f3//ICAgICAgICAIABQAAgAAAH9/f/8gICAgICAgIAkAFAACAAAA f39///gLwGAAC8AACgAUAAIAAAB/f3//AAAAAAAAAAB9CEEAfQgAAAAAAAAAAAAAAAA4AAAA AwANABQAAgAAAPp9AP8wMFwpO18oKg4ABQACCAAUAAIAAAD/gAH/O18oQF8pICB9CEEAfQgA AAAAAAAAAAAAAAA5AAAAAwANABQAAgAAAJxlAP8wMFwpO18oKg4ABQACBAAUAAIAAAD/65z/ O18oQF8pICB9CHgAfQgAAAAAAAAAAAAAAAA6AAAABQAEABQAAgAAAP//zP8wMFwpO18oKgcA FAACAAAAsrKy/wD/65z/O18oCAAUAAIAAACysrL/AH9/f/8gICAJABQAAgAAALKysv8Af39/ /yAgIAoAFAACAAAAsrKy/wB/f3//+AvAfQiRAH0IAAAAAAAAAAAAAAAAOwAAAAcADQAUAAIA AAA/Pz//MDBcKTtfKCoOAAUAAgQAFAACAAAA8vLy/ztfKAgAFAACBwAUAAIAAAA/Pz//ICAg CQAUAAIIABQAAgAAAD8/P/8gICAKABQAAgkAFAACAAAAPz8///gLwGAAC8AACgAUAAIAAAA/ Pz//AAAAAAAAAAB9CC0AfQgAAAAAAAAAAAAAAAA9AAAAAgANABQAAwAAAAMAAAAwMFwpO18o Kg4ABQABfQhVAH0IAAAAAAAAAAAAAAAAPgAAAAQADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUA AgcAFAADAAAABAAAADtfKAgAFAACCAAUAAMAAAAEAAAAICAgCQAUAAJ9CC0AfQgAAAAAAAAA AAAAAAA/AAAAAgANABQAAgAAAP8AAP8wMFwpO18oKg4ABQACfQgoAH0IAAAAAAAAAAAAAAAA SwAAAAEADQAUAAIAAAAAAAD/MDBcKTtfKCp9CCgAfQgAAAAAAAAAAAAAAABPAAAAAQANABQA AgAAAAAAAP8wMFwpO18oKo0IOQCNCAAAAAAAAAAAAAADAAAABQACAAwAAzQAAP+ZAP8FAAwA AwoAAN0IBv8gAAUAACEABQAAJQAFAACNCD4AjQgAAAAAAAAAAAAAAwAAAAYAAAAFAAACAAwA A0EAAP////8FAAwAAUAAAAAAAAAgAAUAACEABQAAJQAFAACNCD4AjQgAAAAAAAAAAAAAAwAA AAYAAAAFAAACAAwAA0EAAP////8FAAwAAUAAAAAAAAAgAAUAACEABQAAJQAFAACNCDkAjQgA AAAAAAAAAAAAAwAAAAUAAgAMAAM0AAD/mQD/BQAMAAMKAADdCAb/IAAFAAAhAAUAACUABQAA jQg5AI0IAAAAAAAAAAAAAAMAAAAFAAIADAADNAAA/5kA/wUADAADCgAA3QgG/yAABQAAIQAF AAAlAAUAAI0IOQCNCAAAAAAAAAAAAAADAAAABQACAAwAAzQAAP+ZAP8FAAwAAwoAAN0IBv8g AAUAACEABQAAJQAFAACNCDkAjQgAAAAAAAAAAAAAAwAAAAUAAgAMAAM0AAD/mQD/BQAMAAMK AADdCAb/IAAFAAAhAAUAACUABQAAjQg+AI0IAAAAAAAAAAAAAAMAAAAGAAAABQAAAgAMAANB AAD/////BQAMAAFAAAAAAAAAIAAFAAAhAAUAACUABQAAjQg5AI0IAAAAAAAAAAAAAAMAAAAF AAIADAADNAAA/5kA/wUADAADCgAA3QgG/yAABQAAIQAFAAAlAAUAAI0IOQCNCAAAAAAAAAAA AAADAAAABQACAAwAAzMAAP/MAP8FAAwAAwoAAN0IBv8gAAUAACEABQAAJQAFAACNCDkAjQgA AAAAAAAAAAAAAwAAAAUAAgAMAAM0AAD/mQD/BQAMAAMKAADdCAb/IAAFAAAhAAUAACUABQAA jQg+AI0IAAAAAAAAAAAAAAMAAAAGAAAABQAAAgAMAANBAAD/////BQAMAAFAAAAAAAAAIAAF AAAhAAUAACUABQAAjQg5AI0IAAAAAAAAAAAAAAMAAAAFAAIADAADNAAA/5kA/wUADAADCgAA 3QgG/yAABQAAIQAFAAAlAAUAAI0IPgCNCAAAAAAAAAAAAAADAAAABgAAAAUAAAIADAADQQAA /////wUADAABQAAAAAAAACAABQAAIQAFAAAlAAUAAI0IOQCNCAAAAAAAAAAAAAADAAAABQAC AAwAAzQAAP+ZAP8FAAwAAwoAAN0IBv8gAAUAACEABQAAJQAFAACTAhIAEAANAAAyMCUgLSBB Y2NlbnQxkghNAJIIAAAAAAAAAAAAAAEEHv8NADIAMAAlACAALQAgAEEAYwBjAGUAbgB0ADEA AAADAAEADAAHBGVm3Obx/wUADAAHAQAAAAAA/yUABQACkwISABEADQAAMjAlIC0gQWNjZW50 MpIITQCSCAAAAAAAAAAAAAABBCL/DQAyADAAJQAgAC0AIABBAGMAYwBlAG4AdAAyAAAAAwAB AAwABwVlZvLc2/8FAAwABwEAAAAAAP8lAAUAApMCEgASAA0AADIwJSAtIEFjY2VudDOSCE0A kggAAAAAAAAAAAAAAQQm/w0AMgAwACUAIAAtACAAQQBjAGMAZQBuAHQAMwAAAAMAAQAMAAcG ZWbr8d7/BQAMAAcBAAAAAAD/JQAFAAKTAhIAEwANAAAyMCUgLSBBY2NlbnQ0kghNAJIIAAAA AAAAAAAAAAEEKv8NADIAMAAlACAALQAgAEEAYwBjAGUAbgB0ADQAAAADAAEADAAHB2Vm5N/s /wUADAAHAQAAAAAA/yUABQACkwISABQADQAAMjAlIC0gQWNjZW50NZIITQCSCAAAAAAAAAAA AAABBC7/DQAyADAAJQAgAC0AIABBAGMAYwBlAG4AdAA1AAAAAwABAAwABwhlZtru8/8FAAwA BwEAAAAAAP8lAAUAApMCEgAVAA0AADIwJSAtIEFjY2VudDaSCE0AkggAAAAAAAAAAAAAAQQy /w0AMgAwACUAIAAtACAAQQBjAGMAZQBuAHQANgAAAAMAAQAMAAcJZWb96dn/BQAMAAcBAAAA AAD/JQAFAAKTAhIAFgANAAA0MCUgLSBBY2NlbnQxkghNAJIIAAAAAAAAAAAAAAEEH/8NADQA MAAlACAALQAgAEEAYwBjAGUAbgB0ADEAAAADAAEADAAHBMxMuMzk/wUADAAHAQAAAAAA/yUA BQACkwISABcADQAANDAlIC0gQWNjZW50MpIITQCSCAAAAAAAAAAAAAABBCP/DQA0ADAAJQAg AC0AIABBAGMAYwBlAG4AdAAyAAAAAwABAAwABwXMTOa4t/8FAAwABwEAAAAAAP8lAAUAApMC EgAYAA0AADQwJSAtIEFjY2VudDOSCE0AkggAAAAAAAAAAAAAAQQn/w0ANAAwACUAIAAtACAA QQBjAGMAZQBuAHQAMwAAAAMAAQAMAAcGzEzY5Lz/BQAMAAcBAAAAAAD/JQAFAAKTAhIAGQAN AAA0MCUgLSBBY2NlbnQ0kghNAJIIAAAAAAAAAAAAAAEEK/8NADQAMAAlACAALQAgAEEAYwBj AGUAbgB0ADQAAAADAAEADAAHB8xMzMDa/wUADAAHAQAAAAAA/yUABQACkwISABoADQAANDAl IC0gQWNjZW50NZIITQCSCAAAAAAAAAAAAAABBC//DQA0ADAAJQAgAC0AIABBAGMAYwBlAG4A dAA1AAAAAwABAAwABwjMTLfe6P8FAAwABwEAAAAAAP8lAAUAApMCEgAbAA0AADQwJSAtIEFj Y2VudDaSCE0AkggAAAAAAAAAAAAAAQQz/w0ANAAwACUAIAAtACAAQQBjAGMAZQBuAHQANgAA AAMAAQAMAAcJzEz81bT/BQAMAAcBAAAAAAD/JQAFAAKTAhIAHAANAAA2MCUgLSBBY2NlbnQx kghNAJIIAAAAAAAAAAAAAAEEIP8NADYAMAAlACAALQAgAEEAYwBjAGUAbgB0ADEAAAADAAEA DAAHBDIzlbPX/wUADAAHAAAA/////yUABQACkwISAB0ADQAANjAlIC0gQWNjZW50MpIITQCS CAAAAAAAAAAAAAABBCT/DQA2ADAAJQAgAC0AIABBAGMAYwBlAG4AdAAyAAAAAwABAAwABwUy M9qWlP8FAAwABwAAAP////8lAAUAApMCEgAeAA0AADYwJSAtIEFjY2VudDOSCE0AkggAAAAA AAAAAAAAAQQo/w0ANgAwACUAIAAtACAAQQBjAGMAZQBuAHQAMwAAAAMAAQAMAAcGMjPE15v/ BQAMAAcAAAD/////JQAFAAKTAhIAHwANAAA2MCUgLSBBY2NlbnQ0kghNAJIIAAAAAAAAAAAA AAEELP8NADYAMAAlACAALQAgAEEAYwBjAGUAbgB0ADQAAAADAAEADAAHBzIzsaDH/wUADAAH AAAA/////yUABQACkwISACAADQAANjAlIC0gQWNjZW50NZIITQCSCAAAAAAAAAAAAAABBDD/ DQA2ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA1AAAAAwABAAwABwgyM5LN3P8FAAwABwAAAP// //8lAAUAApMCEgAhAA0AADYwJSAtIEFjY2VudDaSCE0AkggAAAAAAAAAAAAAAQQ0/w0ANgAw ACUAIAAtACAAQQBjAGMAZQBuAHQANgAAAAMAAQAMAAcJMjP6v4//BQAMAAcAAAD/////JQAF AAKTAgwAIgAHAABBY2NlbnQxkghBAJIIAAAAAAAAAAAAAAEEHf8HAEEAYwBjAGUAbgB0ADEA AAADAAEADAAHBAAAT4G9/wUADAAHAAAA/////yUABQACkwIMACMABwAAQWNjZW50MpIIQQCS CAAAAAAAAAAAAAABBCH/BwBBAGMAYwBlAG4AdAAyAAAAAwABAAwABwUAAMBQTf8FAAwABwAA AP////8lAAUAApMCDAAkAAcAAEFjY2VudDOSCEEAkggAAAAAAAAAAAAAAQQl/wcAQQBjAGMA ZQBuAHQAMwAAAAMAAQAMAAcGAACbu1n/BQAMAAcAAAD/////JQAFAAKTAgwAJQAHAABBY2Nl bnQ0kghBAJIIAAAAAAAAAAAAAAEEKf8HAEEAYwBjAGUAbgB0ADQAAAADAAEADAAHBwAAgGSi /wUADAAHAAAA/////yUABQACkwIMACYABwAAQWNjZW50NZIIQQCSCAAAAAAAAAAAAAABBC3/ BwBBAGMAYwBlAG4AdAA1AAAAAwABAAwABwgAAEusxv8FAAwABwAAAP////8lAAUAApMCDAAn AAcAAEFjY2VudDaSCEEAkggAAAAAAAAAAAAAAQQx/wcAQQBjAGMAZQBuAHQANgAAAAMAAQAM AAcJAAD3lkb/BQAMAAcAAAD/////JQAFAAKTAggAKAADAABCYWSSCDkAkggAAAAAAAAAAAAA AQEb/wMAQgBhAGQAAAADAAEADAAF/wAA/8fO/wUADAAF/wAAnAAG/yUABQACkwIQACkACwAA Q2FsY3VsYXRpb26SCIEAkggAAAAAAAAAAAAAAQIW/wsAQwBhAGwAYwB1AGwAYQB0AGkAbwBu AAAABwABAAwABf8AAPLy8v8FAAwABf8AAPp9AP8lAAUAAgYADgAF/wAAf39//wEABwAOAAX/ AAB/f3//AQAIAA4ABf8AAH9/f/8BAAkADgAF/wAAf39//wEAkwIPACoACgAAQ2hlY2sgQ2Vs bJIIfwCSCAAAAAAAAAAAAAABAhf/CgBDAGgAZQBjAGsAIABDAGUAbABsAAAABwABAAwABf8A AKWlpf8FAAwABwAAAP////8lAAUAAgYADgAF/wAAPz8//wYABwAOAAX/AAA/Pz//BgAIAA4A Bf8AAD8/P/8GAAkADgAF/wAAPz8//wYAkwIEACuAA/+SCCAAkggAAAAAAAAAAAAAAQUD/wUA QwBvAG0AbQBhAAAAAACTAgQALIAG/5IIKACSCAAAAAAAAAAAAAABBQb/CQBDAG8AbQBtAGEA IABbADAAXQAAAAAAkwIEAC2ABP+SCCYAkggAAAAAAAAAAAAAAQUE/wgAQwB1AHIAcgBlAG4A YwB5AAAAAACTAgQALoAH/5IILgCSCAAAAAAAAAAAAAABBQf/DABDAHUAcgByAGUAbgBjAHkA IABbADAAXQAAAAAAkwIVAC8AEAAARXhwbGFuYXRvcnkgVGV4dJIIRwCSCAAAAAAAAAAAAAAB AjX/EABFAHgAcABsAGEAbgBhAHQAbwByAHkAIABUAGUAeAB0AAAAAgAFAAwABf8AAH9/f/8l AAUAApMCBAAwgAn/kgg6AJIIAAAAAAAAAAAAAAECCf8SAEYAbwBsAGwAbwB3AGUAZAAgAEgA eQBwAGUAcgBsAGkAbgBrAAAAAACTAgkAMQAEAABHb29kkgg7AJIIAAAAAAAAAAAAAAEBGv8E AEcAbwBvAGQAAAADAAEADAAF/wAAxu/O/wUADAAF/wAAAGEA/yUABQACkwIOADIACQAASGVh ZGluZyAxkghHAJIIAAAAAAAAAAAAAAEDEP8JAEgAZQBhAGQAaQBuAGcAIAAxAAAAAwAFAAwA BwMAAB9Jff8lAAUAAgcADgAHBAAAT4G9/wUAkwIOADMACQAASGVhZGluZyAykghHAJIIAAAA AAAAAAAAAAEDEf8JAEgAZQBhAGQAaQBuAGcAIAAyAAAAAwAFAAwABwMAAB9Jff8lAAUAAgcA DgAHBP8/p7/e/wUAkwIOADQACQAASGVhZGluZyAzkghHAJIIAAAAAAAAAAAAAAEDEv8JAEgA ZQBhAGQAaQBuAGcAIAAzAAAAAwAFAAwABwMAAB9Jff8lAAUAAgcADgAHBDIzlbPX/wIAkwIO ADUACQAASGVhZGluZyA0kgg5AJIIAAAAAAAAAAAAAAEDE/8JAEgAZQBhAGQAaQBuAGcAIAA0 AAAAAgAFAAwABwMAAB9Jff8lAAUAApMCBAA2gAj/kggoAJIIAAAAAAAAAAAAAAECCP8JAEgA eQBwAGUAcgBsAGkAbgBrAAAAAACTAgoANwAFAABJbnB1dJIIdQCSCAAAAAAAAAAAAAABAhT/ BQBJAG4AcAB1AHQAAAAHAAEADAAF/wAA/8yZ/wUADAAF/wAAPz92/yUABQACBgAOAAX/AAB/ f3//AQAHAA4ABf8AAH9/f/8BAAgADgAF/wAAf39//wEACQAOAAX/AAB/f3//AQCTAhAAOAAL AABMaW5rZWQgQ2VsbJIISwCSCAAAAAAAAAAAAAABAhj/CwBMAGkAbgBrAGUAZAAgAEMAZQBs AGwAAAADAAUADAAF/wAA+n0A/yUABQACBwAOAAX/AAD/gAH/BgCTAgwAOQAHAABOZXV0cmFs kghBAJIIAAAAAAAAAAAAAAEBHP8HAE4AZQB1AHQAcgBhAGwAAAADAAEADAAF/wAA/+uc/wUA DAAF/wAAnGUA/yUABQACkwIEAACAAP+SCCIAkggAAAAAAAAAAAAAAQEA/wYATgBvAHIAbQBh AGwAAAAAAJMCCQA6AAQAAE5vdGWSCGIAkggAAAAAAAAAAAAAAQIK/wQATgBvAHQAZQAAAAUA AQAMAAX/AAD//8z/BgAOAAX/AACysrL/AQAHAA4ABf8AALKysv8BAAgADgAF/wAAsrKy/wEA CQAOAAX/AACysrL/AQCTAgsAOwAGAABPdXRwdXSSCHcAkggAAAAAAAAAAAAAAQIV/wYATwB1 AHQAcAB1AHQAAAAHAAEADAAF/wAA8vLy/wUADAAF/wAAPz8//yUABQACBgAOAAX/AAA/Pz// AQAHAA4ABf8AAD8/P/8BAAgADgAF/wAAPz8//wEACQAOAAX/AAA/Pz//AQCTAgQAPIAF/5II JACSCAAAAAAAAAAAAAABBQX/BwBQAGUAcgBjAGUAbgB0AAAAAACTAgoAPQAFAABUaXRsZZII MQCSCAAAAAAAAAAAAAABAw//BQBUAGkAdABsAGUAAAACAAUADAAHAwAAH0l9/yUABQABkwIK AD4ABQAAVG90YWySCE0AkggAAAAAAAAAAAAAAQMZ/wUAVABvAHQAYQBsAAAABAAFAAwABwEA AAAAAP8lAAUAAgYADgAHBAAAT4G9/wEABwAOAAcEAABPgb3/BgCTAhEAPwAMAABXYXJuaW5n IFRleHSSCD8AkggAAAAAAAAAAAAAAQIL/wwAVwBhAHIAbgBpAG4AZwAgAFQAZQB4AHQAAAAC AAUADAAF/wAA/wAA/yUABQACjghYAI4IAAAAAAAAAAAAAJAAAAARABEAVABhAGIAbABlAFMA dAB5AGwAZQBNAGUAZABpAHUAbQA5AFAAaQB2AG8AdABTAHQAeQBsAGUATQBlAGQAaQB1AG0A NACSAOIAOAAAAAAA////AN0IBgAftxQAAADUAPzzBQDyCIQAAKvqAJAAAAAAZBEAAACQAJBx OgBGAKUAAICAAMDAwACAgIAAmZn/AJkzZgD//8wAzP//AGYAZgD/gIAAAGbMAMzM/wAAAIAA /wD/AP//AAAA//8AgACAAIAAAAAAgIAAAAD/AADM/wDM//8AzP/MAP//mQCZzP8A/5nMAMyZ /wD/zJkAM2b/ADPMzACZzAAA/8wAAP+ZAAD/ZgAAZmaZAJaWlgAAM2YAM5lmAAAzAAAzMwAA mTMAAJkzZgAzM5kAMzMzAFwQDgADAAAAAAD///8AAAAAAGABAgAAAIUAEgAsZQAAAAAKAERh dGEgTW9kZWyFABEAj+YAAAAACQBUTEQgU3RhdHOFAA4Ae+8AAAAABgBTaGVldDSaCBgAmggA AAAAAAAAAAAAAAAAAAAAAAACAAAAowgQAKMIAAAAAAAAAAAAAAAAAACMAAQAAQABAK4BBAAD AAEEFwAIAAEAAAAAAAAAwQEIAMEBAADhIgIA1ggQANYIAAAAAAAAAAAAAAIAAAD8ABwgRgUA AJMBAAANAAQQAAAAQ3JlYXRpb24gRGF0ZQEADAAGADcAAAAAAAAAAAAPAAQQAAAARXhwaXJh dGlvbiBEYXRlAQAMAAYANwAAAAAAAAAAAAYABBAAAABTdGF0dXMBAAwABgA3AAAAAAAAAAAA BQAEEAAAAC5BU0lBAQAMAAYANwAAAAAAAAAAAAQABBAAAAAuT1JHAQAMAAYANwAAAAAAAAAA AAUABBAAAAAuQUVSTwEADAAGADcAAAAAAAAAAAAFAAQQAAAALklORk8BAAwABgA3AAAAAAAA AAAABAAEEAAAAC5CSVoBAAwABgA3AAAAAAAAAAAADgAAVHJhZGVtYXJrIE5hbWUOAABUcmFk ZW1hcmsgRGF0ZREAAFRyYWRlbWFyayBDb3VudHJ5EAAAVHJhZGVtYXJrIE51bWJlcgsABBAA AABEb21haW4gTmFtZQEADAAGADcAAAAAAAAAAAAMAAQQAAAAVXBkYXRlZCBEYXRlAQAMAAYA NwAAAAAAAAAAAAkABBAAAABSZWdpc3RyYXIBAAwABgA3AAAAAAAAAAAAJAAEEAAAAERvbWFp biBTdGF0dXMgKGVhY2ggc3RhdHVzIG9uZSBsaW5lKQEADAAGADcAAAAAAAAAAAAdAAQQAAAA U3RhdHVzIChlYWNoIHN0YXR1cyBvbmUgbGluZSkBAAwABgA3AAAAAAAAAAAAHwAEEAAAAE5h bWUgU2VydmVyIChlYWNoIG9uZSBvbmUgbGluZSkBAAwABgA3AAAAAAAAAAAAHAAAQmlsbGlu ZyBDb250YWN0IENvdW50cnkgQ29kZRwAAEJpbGxpbmcgQ29udGFjdCBQaG9uZSBOdW1iZXIg AABCaWxsaW5nIENvbnRhY3QgRmFjc2ltaWxlIE51bWJlchUAAEJpbGxpbmcgQ29udGFjdCBF bWFpbBQAAFRlY2huaWNhbCBDb250YWN0IElEFgAAVGVjaG5pY2FsIENvbnRhY3QgTmFtZR4A AFRlY2huaWNhbCBDb250YWN0IE9yZ2FuaXphdGlvbhoAAFRlY2huaWNhbCBDb250YWN0IEFk ZHJlc3MxGgAAVGVjaG5pY2FsIENvbnRhY3QgQWRkcmVzczIWAABUZWNobmljYWwgQ29udGFj dCBDaXR5IAAAVGVjaG5pY2FsIENvbnRhY3QgU3RhdGUvUHJvdmluY2UdAABUZWNobmljYWwg Q29udGFjdCBQb3N0YWwgQ29kZRkAAFRlY2huaWNhbCBDb250YWN0IENvdW50cnkeAABUZWNo bmljYWwgQ29udGFjdCBDb3VudHJ5IENvZGUeAABUZWNobmljYWwgQ29udGFjdCBQaG9uZSBO dW1iZXIiAABUZWNobmljYWwgQ29udGFjdCBGYWNzaW1pbGUgTnVtYmVyFwAAVGVjaG5pY2Fs IENvbnRhY3QgRW1haWwPAAAgICBSZWZlcnJhbCBVUkwTAABSZWdpc3RyYW50IEFkZHJlc3Mx FwAAUmVnaXN0cmFudCBDb3VudHJ5IENvZGUZAABBZG1pbmlzdHJhdGl2ZSBDb250YWN0IElE GwAAQWRtaW5pc3RyYXRpdmUgQ29udGFjdCBOYW1lIwAAQWRtaW5pc3RyYXRpdmUgQ29udGFj dCBPcmdhbml6YXRpb24fAABBZG1pbmlzdHJhdGl2ZSBDb250YWN0IEFkZHJlc3MxHwAAQWRt aW5pc3RyYXRpdmUgQ29udGFjdCBBZGRyZXNzMhsAAEFkbWluaXN0cmF0aXZlIENvbnRhY3Qg Q2l0eSUAAEFkbWluaXN0cmF0aXZlIENvbnRhY3QgU3RhdGUvUHJvdmluY2UiAABBZG1pbmlz dHJhdGl2ZSBDb250YWN0IFBvc3RhbCBDb2RlHgAAQWRtaW5pc3RyYXRpdmUgQ29udGFjdCBD b3VudHJ5IwAAQWRtaW5pc3RyYXRpdmUgQ29udGFjdCBDb3VudHJ5IENvZGUjAABBZG1pbmlz dHJhdGl2ZSBDb250YWN0IFBob25lIE51bWJlcg8AACAgIFdob2lzIFNlcnZlchgAAEJpbGxp bmcgQ29udGFjdCBBZGRyZXNzMhQAAEJpbGxpbmcgQ29udGFjdCBDaXR5HgAAQmlsbGluZyBD b250YWN0IFN0YXRlL1Byb3ZpbmNlGwAAQmlsbGluZyBDb250YWN0IFBvc3RhbCBDb2RlFwAA QmlsbGluZyBDb250YWN0IENvdW50cnkPAABFeHBpcmF0aW9uIERhdGUGAABTdGF0dXMGAABE TlNTRUMbAABEUyBNYXhpbXVtIFNpZ25hdHVyZSBMaWZlIDEbAABEUyBNYXhpbXVtIFNpZ25h dHVyZSBMaWZlIDIWAABDRUQgRm9ybSBvZiBJRCAoT3RoZXIpGQAAQ0VEIElkZW50aWZpY2F0 aW9uIE51bWJlch8AAE9wZXJhdGlvbnMgYW5kIE5vdGlmaWNhdGlvbnMgSUQhAABPcGVyYXRp b25zIGFuZCBOb3RpZmljYXRpb25zIE5hbWUpAABPcGVyYXRpb25zIGFuZCBOb3RpZmljYXRp b25zIE9yZ2FuaXphdGlvbiQAAE9wZXJhdGlvbnMgYW5kIE5vdGlmaWNhdGlvbnMgQWRkcmVz cxQAAENyZWF0ZWQgYnkgUmVnaXN0cmFyGAAARG9tYWluIFJlZ2lzdHJhdGlvbiBEYXRlEgAA UmVnaXN0cmFudCBTdHJlZXQxEgAAUmVnaXN0cmFudCBTdHJlZXQyEgAAUmVnaXN0cmFudCBT dHJlZXQzDQAAQWRtaW4gU3RyZWV0MQ0AAEFkbWluIFN0cmVldDINAABBZG1pbiBTdHJlZXQz CwAAQWRtaW4gUGhvbmUQAABBZG1pbiBQaG9uZSBFeHQuCQAAQWRtaW4gRkFYDgAAQWRtaW4g RkFYIEV4dC4PAABCaWxsaW5nIFN0cmVldDEPAABCaWxsaW5nIFN0cmVldDIPAABCaWxsaW5n IFN0cmVldDMXAABSZWdpc3RyYXRpb24gQWdlbnQgQ2l0eSEAAFJlZ2lzdHJhdGlvbiBBZ2Vu dCBTdGF0ZS9Qcm92aW5jZSIAAFJlZ2lzdHJhdGlvbiBBZ2VudCBDb3VudHJ5L0Vjb25vbXke AABSZWdpc3RyYXRpb24gQWdlbnQgUG9zdGFsIENvZGUYAABSZWdpc3RyYXRpb24gQWdlbnQg UGhvbmUdAABSZWdpc3RyYXRpb24gQWdlbnQgUGhvbmUgRXh0LhYAAFJlZ2lzdHJhdGlvbiBB Z2VudCBGQVgbAABSZWdpc3RyYXRpb24gQWdlbnQgRkFYIEV4dC4ZAABSZWdpc3RyYXRpb24g QWdlbnQgRS1tYWlsDgAATWFpbnRhaW5lciBVUkwTAABSZWdpc3RyYW50IEFkZHJlc3MyEwAA UmVnaXN0cmFudCBBZGRyZXNzMxoAAFJlZ2lzdHJhbnQgQ291bnRyeS9FY29ub215JwAAQWRt aW5pc3RyYXRpdmUgQ29udGFjdCBGYWNzaW1pbGUgTnVtYmVyHAAAQWRtaW5pc3RyYXRpdmUg Q29udGFjdCBFbWFpbBIAAEJpbGxpbmcgQ29udGFjdCBJRBQAAEJpbGxpbmcgQ29udGFjdCBO YW1lHAAAQmlsbGluZyBDb250YWN0IE9yZ2FuaXphdGlvbhgAAEJpbGxpbmcgQ29udGFjdCBB ZGRyZXNzMQwAAFRlY2ggU3RyZWV0MQwAAFRlY2ggU3RyZWV0MgwAAFRlY2ggU3RyZWV0MwoA AFRlY2ggUGhvbmUPAABUZWNoIFBob25lIEV4dC4IAABUZWNoIEZBWA0AAFRlY2ggRkFYIEV4 dC4PAABMYXN0IFVwZGF0ZWQgT24SAABUZWNobmljYWwgRkFYIEV4dC4QAABUZWNobmljYWwg RS1tYWlsEAAAQmlsbGluZyBBZGRyZXNzMhAAAEJpbGxpbmcgQWRkcmVzczMXAABCaWxsaW5n IENvdW50cnkvRWNvbm9teQ0AAEJpbGxpbmcgUGhvbmUSAABCaWxsaW5nIFBob25lIEV4dC4L AABCaWxsaW5nIEZBWBAAAEJpbGxpbmcgRkFYIEV4dC4OAABCaWxsaW5nIEUtbWFpbAYAAENF RCBJRA8AAENFRCBDQyBMb2NhbGl0eRIAAENFRCBTdGF0ZS9Qcm92aW5jZQgAAENFRCBDaXR5 GAAAQ0VEIFR5cGUgb2YgTGVnYWwgRW50aXR5EAAAQ0VEIFR5cGUgKE90aGVyKRoAAENFRCBG b3JtIG9mIElkZW50aWZpY2F0aW9uDwAAQmlsbGluZyBBZGRyZXNzDAAAQmlsbGluZyBDaXR5 FgAAQmlsbGluZyBTdGF0ZS9Qcm92aW5jZQ8AAEJpbGxpbmcgQ291bnRyeRMAAEJpbGxpbmcg UG9zdGFsIENvZGUNAABCaWxsaW5nIEVtYWlsCgAATWFpbnRhaW5lcgoAAENyZWF0ZWQgQnkK AABVcGRhdGVkIEJ5CgAAQ3JlYXRlZCBPbgoAAEV4cGlyZXMgT24KAABVcGRhdGVkIE9uEgAA RG9tYWluIENyZWF0ZSBEYXRlFgAARG9tYWluIEV4cGlyYXRpb24gRGF0ZRgAAERvbWFpbiBM YXN0IFVwZGF0ZWQgRGF0ZRUAAExhc3QgVHJhbnNmZXJyZWQgRGF0ZQgAAElQUiBOYW1lCgAA SVBSIE51bWJlcg8AAElQUiBDQyBMb2NhbGl0eQsAAElQUiBBcHBsaWVkDgAASVBSIFJlZ2lz dGVyZWQJAABJUFIgQ2xhc3MIAABJUFIgZm9ybQ8AAElQUiBFbnRpdGxlbWVudAgAAElQUiBU eXBlJQAAT3BlcmF0aW9ucyBhbmQgTm90aWZpY2F0aW9ucyBBZGRyZXNzMiUAAE9wZXJhdGlv bnMgYW5kIE5vdGlmaWNhdGlvbnMgQWRkcmVzczMhAABPcGVyYXRpb25zIGFuZCBOb3RpZmlj YXRpb25zIENpdHkrAABPcGVyYXRpb25zIGFuZCBOb3RpZmljYXRpb25zIFN0YXRlL1Byb3Zp bmNlLAAAT3BlcmF0aW9ucyBhbmQgTm90aWZpY2F0aW9ucyBDb3VudHJ5L0Vjb25vbXkoAABP cGVyYXRpb25zIGFuZCBOb3RpZmljYXRpb25zIFBvc3RhbCBDb2RlIgAAT3BlcmF0aW9ucyBh bmQgTm90aWZpY2F0aW9ucyBQaG9uZScAAE9wZXJhdGlvbnMgYW5kIE5vdGlmaWNhdGlvbnMg UGhvbmUgRXh0LiAAAE9wZXJhdGlvbnMgYW5kIE5vdGlmaWNhdGlvbnMgRkFYJQAAT3BlcmF0 aW9ucyBhbmQgTm90aWZpY2F0aW9ucyBGQVggRXh0LiMAAE9wZXJhdGlvbnMgYW5kIE5vdGlm aWNhdGlvbnMgRS1tYWlsCgAARU5TX0F1dGhJZAoAAENyZWF0ZWQgYnkZAABMYXN0IFVwZGF0 ZWQgYnkgUmVnaXN0cmFyFQAAUmVnaXN0cmF0aW9uIEFnZW50IElEFwAAUmVnaXN0cmF0aW9u IEFnZW50IE5hbWUfAABSZWdpc3RyYXRpb24gQWdlbnQgT3JnYW5pemF0aW9uGgAAUmVnaXN0 cmF0aW9uIEFnZW50IEFkZHJlc3MbAABSZWdpc3RyYXRpb24gQWdlbnQgQWRkcmVzczIbAABS ZWdpc3RyYXRpb24gQWdlbnQgQWRkcmVzczMJAABEb21haW4gSUQLAABEb21haW4gTmFtZRQA AFNwb25zb3JpbmcgUmVnaXN0cmFyDQAAUmVnaXN0cmFudCBJRAgAAEFkbWluIElECgAAQWRt aW4gTmFtZRIAAEFkbWluIE9yZ2FuaXphdGlvbgoAAEFkbWluIENpdHkUAABBZG1pbiBTdGF0 ZS9Qcm92aW5jZQ0AAEFkbWluIENvdW50cnkRAABBZG1pbiBQb3N0YWwgQ29kZQsAAEFkbWlu IEVtYWlsBwAAVGVjaCBJRAkAAFRlY2ggTmFtZREAAFRlY2ggT3JnYW5pemF0aW9uCQAAVGVj aCBDaXR5EwAAVGVjaCBTdGF0ZS9Qcm92aW5jZQwAAFRlY2ggQ291bnRyeRAAAFRlY2ggUG9z dGFsIENvZGUKAABUZWNoIEVtYWlsCgAAQmlsbGluZyBJRAwAAEJpbGxpbmcgTmFtZRQAAEJp bGxpbmcgT3JnYW5pemF0aW9uDQAARG9tYWluIFN0YXR1cw8AAFJlZ2lzdHJhbnQgTmFtZRcA AFJlZ2lzdHJhbnQgT3JnYW5pemF0aW9uEgAAUmVnaXN0cmFudCBBZGRyZXNzDwAAUmVnaXN0 cmFudCBDaXR5GQAAUmVnaXN0cmFudCBTdGF0ZS9Qcm92aW5jZRIAAFJlZ2lzdHJhbnQgQ291 bnRyeRYAAFJlZ2lzdHJhbnQgUG9zdGFsIENvZGUXAABSZWdpc3RyYW50IFBob25lIE51bWJl chsAAFJlZ2lzdHJhbnQgRmFjc2ltaWxlIE51bWJlchAAAFJlZ2lzdHJhbnQgRW1haWwLAABO YW1lIFNlcnZlchAAAFJlZ2lzdHJhbnQgUGhvbmUVAABSZWdpc3RyYW50IFBob25lIEV4dC4O AABSZWdpc3RyYW50IEZBWBMAAFJlZ2lzdHJhbnQgRkFYIEV4dC4RAABSZWdpc3RyYW50IEUt bWFpbBEAAEFkbWluaXN0cmF0aXZlIElEEwAAQWRtaW5pc3RyYXRpdmUgTmFtZRsAAEFkbWlu aXN0cmF0aXZlIE9yZ2FuaXphdGlvbhYAAEFkbWluaXN0cmF0aXZlIEFkZHJlc3MXAABBZG1p bmlzdHJhdGl2ZSBBZGRyZXNzMhcAAEFkbWluaXN0cmF0aXZlIEFkZHJlc3MzEwAAQWRtaW5p c3RyYXRpdmUgQ2l0eR0AAEFkbWluaXN0cmF0aXZlIFN0YXRlL1Byb3ZpbmNlHgAAQWRtaW5p c3RyYXRpdmUgQ291bnRyeS9FY29ub215GgAAQWRtaW5pc3RyYXRpdmUgUG9zdGFsIENvZGUU AABBZG1pbmlzdHJhdGl2ZSBQaG9uZRkAAEFkbWluaXN0cmF0aXZlIFBob25lIEV4dC4SAABB ZG1pbmlzdHJhdGl2ZSBGQVgXAABBZG1pbmlzdHJhdGl2ZSBGQVggRXh0LhUAAEFkbWluaXN0 cmF0aXZlIEUtbWFpbAwAAFRlY2huaWNhbCBJRA4AAFRlY2huaWNhbCBOYW1lFgAAVGVjaG5p Y2FsIE9yZ2FuaXphdGlvbhEAAFRlY2huaWNhbCBBZGRyZXNzEgAAVGVjaG5pY2FsIEFkZHJl c3MyEgAAVGVjaG5pY2FsIEFkZHJlc3MzDgAAVGVjaG5pY2FsIENpdHkYAABUZWNobmljYWwg U3RhdGUvUHJvdmluY2UZAABUZWNobmljYWwgQ291bnRyeS9FY29ub215FQAAVGVjaG5pY2Fs IFBvc3RhbCBDb2RlDwAAVGVjaG5pY2FsIFBob25lFAAAVGVjaG5pY2FsIFBob25lIEV4dC4N AABUZWNobmljYWwgRkFYHgAAUXVlcmllZCBuaWMuYWVybyAxMSBKdW5lLCAyMDEyHQAAUXVl cmllZCBuaWMuYXNpYSAxMSBKdW5lIDIwMTIIAABEaWdpc3QgMQwAAERTIENyZWF0ZWQgMQwA AERTIEtleSBUYWcgMQsAAEFsZ29yaXRobSAxDQAARGlnZXN0IFR5cGUgMQwAAERTIENyZWF0 ZWQgMgwAAERTIEtleSBUYWcgMgsAAEFsZ29yaXRobSAyDQAARGlnZXN0IFR5cGUgMggAAERp Z2lzdCAyJQAAUXVlcmllZCBuaWMub3JnLCBwaXIub3JnIDExIEp1bmUgMjAxMiIAAFF1ZXJp ZWQgYWZmaWxpYXMuaW5mbyAxMSBKdW5lIDIwMTINAABSZWdpc3RyYXIgVVJMBAAALkNBVA8A AERvbWFpbiBOYW1lIEFDRQ8AAERvbWFpbiBMYW5ndWFnZQwAAFJlZ2lzdHJhciBJRBEAAFJl Z2lzdHJhbnQgU3RyZWV0FAAAUmVnaXN0cmFudCBQaG9uZSBFeHQOAABSZWdpc3RyYW50IEZh eBIAAFJlZ2lzdHJhbnQgRmF4IEV4dAwAAEFkbWluIFN0cmVldA8AAEFkbWluIFBob25lIEV4 dAkAAEFkbWluIEZheA0AAEFkbWluIEZheCBFeHQLAABUZWNoIFN0cmVldA4AAFRlY2ggUGhv bmUgRXh0CAAAVGVjaCBGYXgMAABUZWNoIEZheCBFeHQOAABCaWxsaW5nIFN0cmVldBEAAEJp bGxpbmcgUGhvbmUgRXh0CwAAQmlsbGluZyBGYXgPAABCaWxsaW5nIEZheCBFeHQPAABOYW1l IFNlcnZlciBBQ0UfAABRdWVyaWVkIG5pYy5iaXogb24gMTEgSnVuZSAyMDEyHAAAUXVlcmll ZCBuaWMuY2F0IDExIEp1bmUgMjAxMigAAFJlZ2lzdHJhbnQgU3RyZWV0IChlYWNoIHN0cmVl dCBvbmUgbGluZSkjAABBZG1pbiBTdHJlZXQgKGVhY2ggc3RyZWV0IG9uZSBsaW5lKSQAAFRl Y2ggU3RyZWV0ICgoZWFjaCBzdHJlZXQgb25lIGxpbmUpKQQAAENPT1AhAABRdWVyaWVkIGRv bWFpbnMuY29vcCAxMSBKdW5lIDIwMTILAABFeHBpcnkgRGF0ZRQAAFNwb25zb3JpbmcgcmVn aXN0cmFyFwAAU3BvbnNvcmluZyByZWdpc3RyYXIgSUQNAABDcmVhdGVkIGJ5IElEDwAATGFz dCB1cGRhdGVkIGJ5EgAATGFzdCB1cGRhdGVkIGJ5IElEBwAAQ3JlYXRlZAwAAExhc3QgdXBk YXRlZBAAAExhc3QgdHJhbnNmZXJyZWQMAABDb250YWN0IFR5cGUKAABDb250YWN0IElEBAAA TmFtZQwAAE9yZ2FuaXNhdGlvbggAAFN0cmVldCAxCAAAU3RyZWV0IDIIAABTdHJlZXQgMwQA AENpdHkOAABTdGF0ZS9Qcm92aW5jZQsAAFBvc3RhbCBjb2RlBwAAQ291bnRyeQUAAFZvaWNl CgAAVm9pY2UgZXh0bgMAAEZheAgAAEZheCBleHRuBQAARW1haWwEAAAuQ09NGwAASG9zdCBJ RCAoZWFjaCBvbmUgb25lIGxpbmUpBQAALkpPQnMFAAAuTU9CSRoAAERhdGUgVHJhZGVtYXJr IEFwcGxpZWQgRm9yGQAARGF0ZSBUcmFkZW1hcmsgUmVnaXN0ZXJlZBYAAFN0YXR1cyAoZWFj aCBvbmUgbGluZSkHAAAuTVVTRVVNHwAAUXVlcmllZCBuaWMubXVzZXVtIDExIEp1bmUgMjAx MgQAAC5ORVQFAAAuTkFNRQUAAC5QT1NUBAAALlBSTxEAAFJlZ2lzdHJhdGlvbiBUeXBlEAAA UmVnaXN0cmFudCBTdGF0ZQQAAC5URUwcAABTcG9uc29yaW5nIFJlZ2lzdHJhciBJQU5BIElE JQAAUmVnaXN0cmFyIFVSTCAocmVnaXN0cmF0aW9uIHNlcnZpY2VzKR8AAFF1ZXJpZWQgbmlj LnRlbCBvbiAxMSBKdW5lIDIwMTIHAAAuVFJBVkVMIgAAUXVlcmllZCBuaWMudHJhdmVsIG9u IDExIEp1bmUgMjAxMhQAAFJlZ2lzdHJhbnQgQWRkcmVzcyAxBAAALlhYWBwAAFF1ZXJpZWQg bmljLlhYWCAxMSBKdW5lIDIwMTIcAABRdWVyaWVkIG5pYy5jb20gMTEgSnVuZSAyMDEyHQAA UXVlcmllZCBuaWMuam9icyAxMSBKdW5lIDIwMTIdAABRdWVyaWVkIG5pYy5tb2JpIDExIEp1 bmUgMjAxMhwAAFF1ZXJpZWQgbmljLm5ldCAxMSBKdW5lIDIwMTIcAABRdWVyaWVkIG5pYy5w cm8gMTEgSnVuZSAyMDEyIwAAbmV3IGdUTEQgZ3VpZGVib29rLCBzcGVjaWZpY2F0aW9uIDQM AABXSE9JUyBTZXJ2ZXIMAABSZWZlcnJhbCBVUkwMAABVcGRhdGVkIERhdGUNAABDcmVhdGlv biBEYXRlFAAAUmVnaXN0cnkgRXhwaXJ5IERhdGUdAABEb21haW4gU3RhdHVzIChlYWNoIG9u ZSBsaW5lKRwAAFJlZ2lzdHJhbnQgUGhvbmUgTnVtYmVyIEV4dC4gAABSZWdpc3RyYW50IEZh Y3NpbWlsZSBOdW1iZXIgRXh0Lh8AAEFkbWluaXN0cmF0aXZlIENvbnRhY3QgQWRkcmVzczMn AABBZG1pbmlzdHJhdGl2ZSBDb250YWN0IFBob25lIE51bWJlciBFeHQrAABBZG1pbmlzdHJh dGl2ZSBDb250YWN0IEZhY3NpbWlsZSBOdW1iZXIgRXh0GAAAQmlsbGluZyBDb250YWN0IEFk ZHJlc3MzIAAAQmlsbGluZyBDb250YWN0IFBob25lIE51bWJlciBFeHQkAABCaWxsaW5nIENv bnRhY3QgRmFjc2ltaWxlIE51bWJlciBFeHQaAABUZWNobmljYWwgQ29udGFjdCBBZGRyZXNz MyIAAFRlY2huaWNhbCBDb250YWN0IFBob25lIE51bWJlciBFeHQmAABUZWNobmljYWwgQ29u dGFjdCBGYWNzaW1pbGUgTnVtYmVyIEV4dAgAAFJlZ2lzdHJ5BAAAQUVSTwQAAEFTSUEDAABD QVQMAABXaG9pcyBTZXJ2ZXIKAABNT0JJLCBJTkZPBAAATU9CSQQAAElORk8DAABPUkcKAABP UkcsIElDQU5OPAAVBAMAAFBSTwkAAFRFTC9JQ0FOTg4AAFRFTC9UUkFWRUwvQklaDQAALm5U TEQgKElDQU5OKR8AAEFkZGl0aW9uYWwgUmVnaXN0cnkgRGF0YSBGaWVsZHMfAABSZWdpc3Ry eSBTcGVjaWZpYyBPVVRQVVQgRmllbGRzHAAAQXBwZW5kaXggUyBvZiBQT1NUIGFncmVlbWVu dBsAAFJlZ2lzdHJ5IE9wZXJhdG9yIFJlZ2lzdHJhch4AAFJlZ2lzdHJhbnQgR2VvZ3JhcGhp YyBsb2NhdGlvbg0AAEFkbWluIEFkZHJlc3MZAABBZG1pbiBHZW9ncmFwaGljIGxvY2F0aW9u EgAAQWRtaW4gUGhvbmUgTnVtYmVyFgAAQWRtaW4gRmFjc2ltaWxlIE51bWJlcgwAAFRlY2gg QWRkcmVzcxgAAFRlY2ggR2VvZ3JhcGhpYyBsb2NhdGlvbhEAAFRlY2ggUGhvbmUgTnVtYmVy FQAAVGVjaCBGYWNzaW1pbGUgTnVtYmVyGwAAQmlsbGluZyBHZW9ncmFwaGljIGxvY2F0aW9u FAAAQmlsbGluZyBQaG9uZSBOdW1iZXIYAABCaWxsaW5nIEZhY3NpbWlsZSBOdW1iZXIOAABU cmFuc2ZlcnJlZCBPbhIAAEFFUk8vQVNJQS9DQVQvUE9TVCYAAE5hbWUgU2VydmVyIChlYWNo IG5hbWVzZXJ2ZXIgb25lIGxpbmUpJgAATmFtZXNlcnZlcnMgKGVhY2ggbmFtZXNlcnZlciBv bmUgbGluZSkkAABIb3N0IE5hbWUgKGVhY2ggbmFtZXNlcnZlciBvbmUgbGluZSkFAABUT1RB TCIAAFRvdGFsIFJlZ2lzdHJhdGlvbnMgYXMgb2YgRmViIDIwMTIDAABUTEQFAAAuQ09PUBwA AENvbGxlY3Rpb24gb2YgRGF0YSBFbGVtZW50cyBMAABJbmRpdmlkdWFsIFJlZ2lzdHJ5IFJl Z2lzdHJhdGlvbiBEYXRhIERpcmVjdG9yeSBTZXJ2aWNlIE91dHB1dCBEYXRhIEVsZW1lbnRz EgAAQ09NL05FVC9KT0JTL0lDQU5ODgAARG9tYWluIE5hbWUgSUQVAABSZWdpc3RyYW50IEZh eCBOdW1iZXIkAABPdGhlciBuYW1lcyByZWdpc3RlcmVkIGJ5IHJlZ2lzdHJhbnQQAABBZG1p biBGYXggTnVtYmVyDwAAVGVjaCBGYXggTnVtYmVyEgAAQmlsbGluZyBGYXggTnVtYmVyTwAA ZGlmZmVyZW50aWF0ZWQgYWNjZXNzLCBhc3N1bWluZyBleHRlbnNpdmUgb3V0cHV0IChBcHBl bmRpeCA1IG9mIE5BTUUgYWdyZWVtZW50KQQAAE5BTUX/AJoBCADDMgAADAAAALQzAAD9AAAA nTQAAOYBAACwNQAA+QIAAKQ2AADtAwAAgDcAAMkEAACcOAAA5QUAAHE5AAC6BgAAOjoAAIMH AAAOOwAAVwgAAJA7AADZCAAAejwAAMMJAABXPQAAoAoAAPc9AABACwAAhD4AAM0LAAAQPwAA WQwAALU/AAD+DAAALkAAAHcNAADGQAAADw4AAGlBAACyDgAAr0IAAPgPAAB8QwAAxRAAABFE AABaEQAAkkQAANsRAAATRQAAXBIAAL5FAAAHEwAAbEYAALUTAAArRwAAdBQAAAFIAABKFQAA oUgAAOoVAABqSQAAsxYAAN1JAAAmFwAAgEoAAMkXAAANSwAAVhgAAIlLAADSGAAAbUwAALYZ AAARTQAAWhoAAHtNAADEGgAA0U0AABobAABSTgAAmxsAAMlOAAASHAAAkk8AANscAAB7UAAA xB0AADFRAAB6HgAAUlIAAJsfAAC9UgAABiAAADBTAABZAAAAClQAADMBAADBVAAA6gEAAIpV AACzAgAAglYAAKsDAACWCJYMlggAAAAAAAAAAAAAAAAAAFBLAwQUAAYACAAAACEAm+hwT/wA AAAcAgAAEwAAAFtDb250ZW50X1R5cGVzXS54bWyskctqwzAQRfeF/oPQtthyuiil2M6ij10f i/QDBnlsi9gjIU1C8vcdOy6UEgKFbgTSzL33zKhcH8ZB7TEm56nSq7zQCsn6xlFX6c/NS3av VWKgBgZPWOkjJr2ur6/KzTFgUqKmVOmeOTwYk2yPI6TcBySptD6OwHKNnQlgt9ChuS2KO2M9 MRJnPHnounzCFnYDq+eDPJ9IRK7V46lviqo0hDA4CyygZqqas7qIQ7og3FPziy5byHJRzuap dyHdLAnvsproGlQfEPkNRuEwLEPiz/MVSEaL+WXmM9G+bZ3FxtvdKOvIZ+PF7E8Aq/+J/s40 89/WXwAAAP//AwBQSwMEFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAABfcmVscy8ucmVsc4SP z2rDMAyH74W9g9F9UdLDGCV2L6WQQy+jfQDhKH9oIhvbG+vbT8cGCrsIhKTv96k9/q6L+eGU 5yAWmqoGw+JDP8to4XY9v3+CyYWkpyUIW3hwhqN727VfvFDRozzNMRulSLYwlRIPiNlPvFKu QmTRyRDSSkXbNGIkf6eRcV/XH5ieGeA2TNP1FlLXN2Cuj6jJ/7PDMMyeT8F/ryzlRQRuN5RM aeRioagv41O9kKhlqtQe0LW4+db9AQAA//8DAFBLAwQUAAYACAAAACEAa3mWFoMAAACKAAAA HAAAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWwMzE0KwyAQQOF9oXeQ2TdjuyhFYrLL rrv2AEOcGkHHoNKf29fl44M3zt8U1ZtLDVksnAcNimXNLoi38Hwspxuo2kgcxSxs4ccV5ul4 GMm0jRPfSchzUX0j1ZCFrbXdINa1K9Uh7yzdXrkkaj2LR1fo0/cp4kXrKyYKAjj9AQAA//8D AFBLAwQUAAYACAAAACEAMA+IaxEHAADeHQAAFgAAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWzs WU9vG0UUvyPxHUZ7b2MndhpHdarYsVto00axW9TjeD32TjO7s5oZJ/ENtUckJERBXJC4cUBA pVbiUj5NoAiK1K/Am5nd9U48bpwSQEBzaL2zv/fmvd/7M3/26rXjmKFDIiTlSTOoXq4EiCQh H9Jk3Azu9ruXNgIkFU6GmPGENIMpkcG1rXffuYo3VURigkA+kZu4GURKpZsrKzKEYSwv85Qk 8G7ERYwVPIrxylDgI9Abs5XVSmV9JcY0CVCCY1B7ZzSiIUF9rTLYypV3GDwmSuqBkImeVk0c CYMdHlQ1Qk5lmwl0iFkzgHmG/KhPjlWAGJYKXjSDivkLVrauruDNTIipBbIlua75y+QygeHB qplTjAfFpNVurXFlp9BvAEzN4zqdTrtTLfQZAA5D8NTaUtZZ625UW7nOEsj+nNfdrtQrNRdf 0r82Z3Oj1WrVG5ktVqkB2Z+1OfxGZb22vergDcji63P4Wmu73V538AZk8etz+O6VxnrNxRtQ xGhyMIfWAe12M+0FZMTZDS98A+AblQw+Q0E2FNmlpxjxRC3KtRg/4KILAA1kWNEEqWlKRjiE LG7jeCAo1hPgTYJLb+xQKOeG9FxIhoKmqhm8n2KoiJm+V8+/ffX8KXr1/MnJw2cnD384efTo 5OH3VpcjeAMn47Lgy68/+f3LD9FvT796+fgzP16W8T9/99FPP37qB0IFzSx68fmTX549efHF x79+89gD3xZ4UIb3aUwkuk2O0D6PwTdDjGs5GYjzSfQjTB0JHIFuj+qOihzg7SlmPlyLuOTd E9A8fMDrkweOrb1ITBT1zHwzih3gLuesxYWXgJt6rhLD/Uky9k8uJmXcPsaHvrnbOHFC25mk 0DXzpHS4b0fEMXOP4UThMUmIQvodPyDE4919Sh1ed2kouOQjhe5T1MLUS0mfDpxEmgndoDHE ZerzGULtcLN7D7U483m9Qw5dJBQEZh7j+4Q5NF7HE4Vjn8o+jlmZ8FtYRT4je1MRlnEdqSDS Y8I46gyJlD6ZOwL8LQX9JoZ+5Q37LpvGLlIoeuDTeQtzXkbu8IN2hOPUh+3RJCpj35MHkKIY 7XHlg+9yt0L0M8QBJwvDfY8SJ9xnN4K7dOyYNEsQ/WYiPLG8TriTv70pG2Fiugy0dKdTxzR5 XdtmFPq2neFt224G27CI+YrnxqlmvQj3L2zRO3iS7BGoivkl6m2Hftuhg/98h15Uyxffl2et GLq03pDYvbbZeccLN94jylhPTRm5Jc3eW8ICNOzCoJYzh05SHMTSCH7qSoYJHNxYYCODBFcf UBX1IpzCvr0aaCVjmakeS5RyCedFM+zVrfGw91f2tFnX5xDbOSRWu3xoh9f0cH7cKNQYq8bm TJtPtKYVLDvZ2pVMKfj2JpNVtVFLz1Y1ppmm6MxWuKwpNudyoLxwDQYLNmFng2A/BCyvw7Ff Tw3nHczIUPNuY5SHxUThrwlR5rV1JMJDYkPkDJfYrJrY5Sk05592z+bI+dgsWAPSzjbCpMXi /FmS5FzBjGQQPF1NLCnXFkvQUTNo1FfrAQpx2gxGcNKFn3EKQZN6L4jZGK6LQiVs1p5Zi6ZI Zx43/FlVhcuLBQXjlHEqpNrBMrIxNK+yULFEz2TtX63XdLJdjAOeZrKcFWsbkCL/mBUQaje0 ZDQioSoHuzSiubOPWSfkE0VELxoeoQGbiH0M4QdOtT9DKuHCwhS0foDbNc22eeX21qzTlO+0 DM6OY5ZGOOuW+nYmrzgLN/2ksME8lcwD37y2G+fO74qu+ItypZzG/zNX9HIANwhrQx2BEC53 BUa6UpoBFyri0IXSiIZdAeu+6R2QLXBDC6+BfLhiNv8Lcqj/tzVndZiyhoOg2qdjJCgsJyoS hOxBWzLZd4ayarb0WJUsU2QyqmSuTK3ZA3JIWF/3wHXdgwMUQaqbbpK1AYM7nX/uc1ZBg7He o5TrzelkxdJpa+Dv3rjYYganTu0ldP7m/BcmFqv7bPWz8kY8XyPLjugXs11SLa8KZ/FrNLKp 3tCEZRbg0lprO9acx6v13DiI4rzHMFjsZ1K4B0L6H1j/qAiZ/V6hF9Q+34feiuDzg+UPQVZf 0l0NMkg3SPtrAPseO2iTSauy1GY7H81avlhf8Ea1mPcU2dqyZeJ9TrKLTZQ7nVOLF0l2xrDD tR1bSDVE9nSJwtAoP4eYwJgPXeVvUXzwAAK9A7f+E2a/TskUnkwdpHvCZNeAD6fZTybtgmuz Tp9hNJIl+2SE6PA4P38UTNgSsl9I8i2yQWsxnWiF4Jrv0OAKZngtalfLQnj1bOFCwswMLbsQ NhdqPgXwfSxr3PpoB3jbZK3XurhypljyZyhbwng/Zd6Tz7KU2YPiawP1BpSp49dTljEF5M0n HnzhFBiOXj3Tf2HRsZluUnbrDwAAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAAGwEAACcA AAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeCdwhv b9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI 93V9oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTf AAAA//8DAFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABb Q29udGVudF9UeXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAA AAAAAAAALQEAAF9yZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAA AAAAAAAAAAAAFgIAAHRoZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAA ACEAMA+IaxEHAADeHQAAFgAAAAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnht bFBLAQItABQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAAAAAAAAAAAAAABgKAAB0aGVtZS90 aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAEwsAAAAA CgAAAAkIEAAABhAAzVbMBxAAAwAGBgAACwIoAAAAAAACAAAAtgAAALp+AADcmgAA8rEAAIjH AADezwAAtNUAACLZAAANAAIAAQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIA AQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAAEAYEAAgDBBBQAAAAVAAAA gwACAAAAhAACAAAATQA8GAMQPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgi Pz4KPCFET0NUWVBFIHBsaXN0IFBVQkxJQyAiLS8vQXBwbGUvL0RURCBQTElTVCAxLjAvL0VO IiAiaHR0cDovL3d3dy5hcHBsZS5jb20vRFREcy9Qcm9wZXJ0eUxpc3QtMS4wLmR0ZCI+Cjxw bGlzdCB2ZXJzaW9uPSIxLjAiPgo8ZGljdD4KCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VG b3JtYXQuUE1Ib3Jpem9udGFsUmVzPC9rZXk+Cgk8ZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5w cmludC50aWNrZXQuY3JlYXRvcjwva2V5PgoJCTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRpY2tl dDwvc3RyaW5nPgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tl eT4KCQk8YXJyYXk+CgkJCTxkaWN0PgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZv cm1hdC5QTUhvcml6b250YWxSZXM8L2tleT4KCQkJCTxyZWFsPjMwMDwvcmVhbD4KCQkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCTxpbnRlZ2Vy PjA8L2ludGVnZXI+CgkJCTwvZGljdD4KCQk8L2FycmF5PgoJPC9kaWN0PgoJPGtleT5jb20u YXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTU9yaWVudGF0aW9uPC9rZXk+Cgk8ZGljdD4KCQk8 a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5PgoJCTxzdHJpbmc+Y29t LmFwcGxlLmpvYnRpY2tldDwvc3RyaW5nPgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tl dC5pdGVtQXJyYXk8L2tleT4KCQk8YXJyYXk+CgkJCTxkaWN0PgoJCQkJPGtleT5jb20uYXBw bGUucHJpbnQuUGFnZUZvcm1hdC5QTU9yaWVudGF0aW9uPC9rZXk+CgkJCQk8aW50ZWdlcj4x PC9pbnRlZ2VyPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxhZzwv a2V5PgoJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJPC9kaWN0PgoJCTwvYXJyYXk+Cgk8 L2RpY3Q+Cgk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNU2NhbGluZzwva2V5 PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4K CQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBs ZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJ CTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1TY2FsaW5nPC9rZXk+CgkJCQk8 cmVhbD4xPC9yZWFsPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRlRmxh Zzwva2V5PgoJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJPC9kaWN0PgoJCTwvYXJyYXk+ Cgk8L2RpY3Q+Cgk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNVmVydGljYWxS ZXM8L2tleT4KCTxkaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9y PC9rZXk+CgkJPHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0PC9zdHJpbmc+CgkJPGtleT5j b20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCTxhcnJheT4KCQkJPGRp Y3Q+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNVmVydGljYWxSZXM8 L2tleT4KCQkJCTxyZWFsPjMwMDwvcmVhbD4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRp Y2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCTwvZGlj dD4KCQk8L2FycmF5PgoJPC9kaWN0PgoJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1h dC5QTVZlcnRpY2FsU2NhbGluZzwva2V5PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJp bnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8 L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+ CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3Jt YXQuUE1WZXJ0aWNhbFNjYWxpbmc8L2tleT4KCQkJCTxyZWFsPjE8L3JlYWw+CgkJCQk8a2V5 PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQk8aW50ZWdlcj4w PC9pbnRlZ2VyPgoJCQk8L2RpY3Q+CgkJPC9hcnJheT4KCTwvZGljdD4KCTxrZXk+Y29tLmFw cGxlLnByaW50LnN1YlRpY2tldC5wYXBlcl9pbmZvX3RpY2tldDwva2V5PgoJPGRpY3Q+CgkJ PGtleT5QTVBQRFBhcGVyQ29kZU5hbWU8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBw bGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUuam9i dGlja2V0PC9zdHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJy YXk8L2tleT4KCQkJPGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5QTVBQRFBhcGVyQ29k ZU5hbWU8L2tleT4KCQkJCQk8c3RyaW5nPkxldHRlcjwvc3RyaW5nPgoJCQkJCTxrZXk+Y29t LmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9p bnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PlBNVGlv Z2FQYXBlck5hbWU8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlj a2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0PC9zdHJp bmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQkJ PGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5QTVRpb2dhUGFwZXJOYW1lPC9rZXk+CgkJ CQkJPHN0cmluZz5uYS1sZXR0ZXI8L3N0cmluZz4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmlu dC50aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJ CTwvZGljdD4KCQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQu UGFnZUZvcm1hdC5QTUFkanVzdGVkUGFnZVJlY3Q8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5j b20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBw bGUuam9idGlja2V0PC9zdHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5p dGVtQXJyYXk8L2tleT4KCQkJPGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5jb20uYXBw bGUucHJpbnQuUGFnZUZvcm1hdC5QTUFkanVzdGVkUGFnZVJlY3Q8L2tleT4KCQkJCQk8YXJy YXk+CgkJCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCQkJCTxpbnRlZ2VyPjA8L2ludGVn ZXI+CgkJCQkJCTxyZWFsPjMwNTguMzMzMzMzMzMzMzMzNTwvcmVhbD4KCQkJCQkJPHJlYWw+ MjQwMDwvcmVhbD4KCQkJCQk8L2FycmF5PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRp Y2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9k aWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdl Rm9ybWF0LlBNQWRqdXN0ZWRQYXBlclJlY3Q8L2tleT4KCQk8ZGljdD4KCQkJPGtleT5jb20u YXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQkJPHN0cmluZz5jb20uYXBwbGUu am9idGlja2V0PC9zdHJpbmc+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5pdGVt QXJyYXk8L2tleT4KCQkJPGFycmF5PgoJCQkJPGRpY3Q+CgkJCQkJPGtleT5jb20uYXBwbGUu cHJpbnQuUGFnZUZvcm1hdC5QTUFkanVzdGVkUGFwZXJSZWN0PC9rZXk+CgkJCQkJPGFycmF5 PgoJCQkJCQk8cmVhbD4tNzU8L3JlYWw+CgkJCQkJCTxyZWFsPi03NTwvcmVhbD4KCQkJCQkJ PHJlYWw+MzIyNS4wMDAwMDAwMDAwMDA1PC9yZWFsPgoJCQkJCQk8cmVhbD4yNDc1PC9yZWFs PgoJCQkJCTwvYXJyYXk+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRl RmxhZzwva2V5PgoJCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCQk8L2RpY3Q+CgkJCTwv YXJyYXk+CgkJPC9kaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhcGVySW5mby5QTVBh cGVyTmFtZTwva2V5PgoJCTxkaWN0PgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQu Y3JlYXRvcjwva2V5PgoJCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4K CQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCQk8YXJy YXk+CgkJCQk8ZGljdD4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1Q YXBlck5hbWU8L2tleT4KCQkJCQk8c3RyaW5nPm5hLWxldHRlcjwvc3RyaW5nPgoJCQkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdl cj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5 PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1VbmFkanVzdGVkUGFnZVJlY3Q8L2tleT4K CQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4K CQkJPHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0PC9zdHJpbmc+CgkJCTxrZXk+Y29tLmFw cGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQkJPGFycmF5PgoJCQkJPGRpY3Q+ CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFwZXJJbmZvLlBNVW5hZGp1c3RlZFBhZ2VS ZWN0PC9rZXk+CgkJCQkJPGFycmF5PgoJCQkJCQk8cmVhbD4wLjA8L3JlYWw+CgkJCQkJCTxy ZWFsPjAuMDwvcmVhbD4KCQkJCQkJPHJlYWw+NzM0PC9yZWFsPgoJCQkJCQk8cmVhbD41NzY8 L3JlYWw+CgkJCQkJPC9hcnJheT4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQu c3RhdGVGbGFnPC9rZXk+CgkJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJCTwvZGljdD4K CQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFwZXJJbmZv LlBNVW5hZGp1c3RlZFBhcGVyUmVjdDwva2V5PgoJCTxkaWN0PgoJCQk8a2V5PmNvbS5hcHBs ZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5PgoJCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0 aWNrZXQ8L3N0cmluZz4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJh eTwva2V5PgoJCQk8YXJyYXk+CgkJCQk8ZGljdD4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmlu dC5QYXBlckluZm8uUE1VbmFkanVzdGVkUGFwZXJSZWN0PC9rZXk+CgkJCQkJPGFycmF5PgoJ CQkJCQk8cmVhbD4tMTg8L3JlYWw+CgkJCQkJCTxyZWFsPi0xODwvcmVhbD4KCQkJCQkJPHJl YWw+Nzc0PC9yZWFsPgoJCQkJCQk8cmVhbD41OTQ8L3JlYWw+CgkJCQkJPC9hcnJheT4KCQkJ CQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQkJPGlu dGVnZXI+MDwvaW50ZWdlcj4KCQkJCTwvZGljdD4KCQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJ PGtleT5jb20uYXBwbGUucHJpbnQuUGFwZXJJbmZvLnBwZC5QTVBhcGVyTmFtZTwva2V5PgoJ CTxkaWN0PgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5PgoJ CQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4KCQkJPGtleT5jb20uYXBw bGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCQk8YXJyYXk+CgkJCQk8ZGljdD4K CQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8ucHBkLlBNUGFwZXJOYW1lPC9r ZXk+CgkJCQkJPHN0cmluZz5VUyBMZXR0ZXI8L3N0cmluZz4KCQkJCQk8a2V5PmNvbS5hcHBs ZS5wcmludC50aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQkJPGludGVnZXI+MDwvaW50ZWdl cj4KCQkJCTwvZGljdD4KCQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJPGtleT5jb20uYXBwbGUu cHJpbnQudGlja2V0LkFQSVZlcnNpb248L2tleT4KCQk8c3RyaW5nPjAwLjIwPC9zdHJpbmc+ CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnR5cGU8L2tleT4KCQk8c3RyaW5nPmNv bS5hcHBsZS5wcmludC5QYXBlckluZm9UaWNrZXQ8L3N0cmluZz4KCTwvZGljdD4KCTxrZXk+ Y29tLmFwcGxlLnByaW50LnRpY2tldC5BUElWZXJzaW9uPC9rZXk+Cgk8c3RyaW5nPjAwLjIw PC9zdHJpbmc+Cgk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQudHlwZTwva2V5PgoJPHN0 cmluZz5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdFRpY2tldDwvc3RyaW5nPgo8L2RpY3Q+ CjwvcGxpc3Q+Ck0AegABAAADAAABLAEsAAAAAAvzCWD/tf+1DJoJqwNnBSgD/AACAAAASABI AAAAAALYAigAAQAAAGQAAAABAAMDAwAAAAF//wABAAEAAAAAAAAAAAAAAABoCAAZAZAAAAAA ACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKEAIgABAGQAAQABAAEAAgD8//z/AAAAAAAA 4D8AAAAAAADgPwEAVQACAAoAfQAMAAAAAAAAI0EABgACAH0ADAABAAEAJBJBAAYAAgB9AAwA AgACANsfQQACAAIAfQAMAAMAAwBtHUEAAgACAH0ADAAEAAQA2x5BAAYAAgB9AAwABQAFANse QQACAAIAfQAMAAYABgDbG0EABgACAH0ADAAHAAcAkh5BAAYAAgB9AAwACAAIAEkbQQACAAIA fQAMAAkACQDbG0EABgACAH0ADAAKAAoA2xtBAAIAAgB9AAwACwALANseQQACAAIAfQAMAAwA DAC2FEEAAgACAH0ADAANAA0A2xtBAAYAAgB9AAwADgAOAEkZQQACAAIAfQAMAA8ADwBJF0EA BgACAH0ADAAQABAA2xtBAAIAAgB9AAwAEQASANseQQAGAAIAfQAMABMAEwBtH0EABgACAH0A DAAUABQAACJBAAYAAgB9AAwAFQAAAbYKQQAAAAIAAAIOAAIAAAC2AAAAAAAVAAAACAIQAAIA AAAVAGgBAAAAAAABDwAIAhAAAwAAABUAaAEAAAAAAAEPAAgCEAAEAAAAFQAQBAAAAACAAUkA CAIQAAUAAAAVAAQBAAAAAAABDwAIAhAABgAAABUABAEAAAAAAAEPAAgCEAAHAAAAFQAEAQAA AAAAAQ8ACAIQAAgAAAAVAAQBAAAAAAABDwAIAhAACQAAABUABAEAAAAAAAEPAAgCEAAKAAAA FQAEAQAAAAAAAQ8ACAIQAAsAAAAVAAQBAAAAAAABDwAIAhAADAAAABUABAEAAAAAAAEPAAgC EAANAAAAFQAEAQAAAAAAAQ8ACAIQAA4AAAAVAAQBAAAAAAABDwAIAhAADwAAABUABAEAAAAA AAEPAAgCEAAQAAAAFQAEAQAAAAAAAQ8ACAIQABEAAAAVAAQBAAAAAAABDwAIAhAAEgAAABUA BAEAAAAAAAEPAAgCEAATAAAAFQAEAQAAAAAAAQ8ACAIQABQAAAAVAAQBAAAAAAABDwAIAhAA FQAAABUABAEAAAAAAAEPAAgCEAAWAAAAFQAEAQAAAAAAAQ8ACAIQABcAAAAVAAQBAAAAAAAB DwAIAhAAGAAAABUABAEAAAAAAAEPAAgCEAAZAAAAFQAEAQAAAAAAAQ8ACAIQABoAAAAVAAQB AAAAAAABDwAIAhAAGwAAABUABAEAAAAAAAEPAAgCEAAcAAAAFQAEAQAAAAAAAQ8ACAIQAB0A AAAVAAQBAAAAAAABDwAIAhAAHgAAABUABAEAAAAAAAEPAAgCEAAfAAAAFQAEAQAAAAAAAQ8A CAIQACAAAAAVAAQBAAAAAAABDwAIAhAAIQAAABUABAEAAAAAAAEPAP0ACgACAAAAQACIAQAA /QAKAAIAAgBTAIkBAAC+ACgAAgADAFMAUwBTAFMAUwBTAFMAUwBTAFMAUwBTAFMAUwBTAFMA UwATAAECBgADAAEAQAD9AAoAAwACAEAABQAAAP0ACgADAAMAQAADAAAA/QAKAAMABABAAAcA AAD9AAoAAwAFAEAA/QAAAP0ACgADAAYAQAAyAQAA/QAKAAMABwBAAIcBAAD9AAoAAwAIAEAA BgAAAP0ACgADAAkAQAA0AQAA/QAKAAMACgBAADUBAAD9AAoAAwALAEAAOQEAAP0ACgADAAwA QAA8AQAA/QAKAAMADQBAADsBAAD9AAoAAwAOAEAABAAAAP0ACgADAA8AQAA9AQAA/QAKAAMA EABAAD4BAAD9AAoAAwARAEAAQQEAAP0ACgADABIAQABFAQAA/QAKAAMAEwBAAEgBAAD9AAoA AwAUAEAAbgEAAP0ACgAEAAIASgDuAAAA/QAKAAQAAwBKAO8AAAD9AAoABAAEAEoAEgEAAP0A CgAEAAUASgATAQAA/QAKAAQABgBKAEoBAAD9AAoABAAHAEoAGAEAAP0ACgAEAAgASgD7AAAA /QAKAAQACQBKAEsBAAD9AAoABAAKAEoATAEAAP0ACgAEAAsASgA6AQAA/QAKAAQADABKAJEB AAD9AAoABAANAEoATQEAAP0ACgAEAA4ASgD6AAAA/QAKAAQADwBKAHEBAAD9AAoABAAQAEoA TgEAAP0ACgAEABEASgBEAQAA/QAKAAQAEgBKAEYBAAD9AAoABAATAEoASQEAAP0ACgAEABQA SgBPAQAA/QAKAAUAAABBAKoAAAD9AAoABQACAEEAqgAAAP0ACgAFAAMAQQCqAAAA/QAKAAUA BABBAKoAAAD9AAoABQAFAEEAqgAAAP0ACgAFAAcAQQCqAAAA/QAKAAUACABBAKoAAAD9AAoA BQAKAEEAqgAAAP0ACgAFAAsAQQCqAAAA/QAKAAUADABBAIsBAAD9AAoABQAOAEEAqgAAAP0A CgAFAA8ASwCqAAAA/QAKAAUAEABBAKoAAAD9AAoABQARAEEAqgAAAP0ACgAFABIAQQCqAAAA /QAKAAUAEwBBAKoAAAD9AAoABQAUAEMAqgAAAP0ACgAGAAAAQQCrAAAA/QAKAAYAAgBBAKsA AAD9AAoABgADAEEAqwAAAP0ACgAGAAQAQQCrAAAA/QAKAAYABQBBAKsAAAD9AAoABgAGAEEA DAAAAP0ACgAGAAcAQQCrAAAA/QAKAAYACABBAKsAAAD9AAoABgAJAEEADAAAAP0ACgAGAAoA QQCrAAAA/QAKAAYACwBBAKsAAAD9AAoABgAMAEEAqwAAAP0ACgAGAA0AQQAMAAAA/QAKAAYA DgBBAKsAAAD9AAoABgAPAEsAqwAAAP0ACgAGABAAQQCrAAAA/QAKAAYAEQBBAKsAAAD9AAoA BgASAEEAqwAAAP0ACgAGABMAQQCrAAAA/QAKAAYAFABDAKsAAAD9AAoABwAAAEEAQwAAAP0A CgAHAAIAQQCGAAAA/QAKAAcAAwBBAIkAAAD9AAoABwAEAEEAQwAAAP0ACgAHAAUAQQCGAAAA /QAKAAcABgBBAAAAAAD9AAoABwAHAEEAHwEAAP0ACgAHAAgAQQCGAAAA/QAKAAcACQBBAAAA AAD9AAoABwAKAEEAhgAAAP0ACgAHAAsAQQCGAAAA/QAKAAcADABBAIYAAAD9AAoABwANAEEA AAAAAP0ACgAHAA4AQQCGAAAA/QAKAAcADwBLAIYAAAD9AAoABwAQAEEAhgAAAP0ACgAHABEA QQBDAAAA/QAKAAcAEgBBAEMAAAD9AAoABwATAEEAhgAAAP0ACgAHABQAQwBTAQAA/QAKAAgA AABBAIoAAAD9AAoACAACAEEAhwAAAP0ACgAIAAMAQwCKAAAA/QAKAAgABABBAIoAAAD9AAoA CAAFAEEANwAAAP0ACgAIAAYAQQABAAAA/QAKAAgABwBBABkBAAD9AAoACAAIAEEANwAAAP0A CgAIAAkAQQABAAAA/QAKAAgACgBBADcAAAD9AAoACAALAEEANwAAAP0ACgAIAAwAQQCHAAAA /QAKAAgADQBBAAEAAAD9AAoACAAOAEEANwAAAP0ACgAIABAAQQA3AAAA/QAKAAgAEQBBAIoA AAD9AAoACAASAEEAigAAAP0ACgAIABMAQQA3AAAA/QAKAAgAFABDAFQBAAD9AAoACQAAAEEA iwAAAP0ACgAJAAIAQQCIAAAA/QAKAAkAAwBBAIsAAAD9AAoACQAEAEEAiwAAAP0ACgAJAAUA QQBrAAAA/QAKAAkABgBBAA0AAAD9AAoACQAHAEEAIAEAAP0ACgAJAAgAQQBrAAAA/QAKAAkA CQBBAA0AAAD9AAoACQAKAEEAawAAAP0ACgAJAAwAQQCIAAAA/QAKAAkADQBBAA0AAAD9AAoA CQAOAEEAawAAAP0ACgAJAA8ASwCIAAAA/QAKAAkAEABBAGsAAAD9AAoACQARAEEAiwAAAP0A CgAJABIAQQCLAAAA/QAKAAkAEwBBAGsAAAD9AAoACQAUAEMAUgEAAP0ACgAKAAAAQQCMAAAA /QAKAAoAAwBBAIwAAAD9AAoACgAHAEEAIQEAAP0ACgAKAA8ASwB/AQAA/QAKAAsAAABBAEIA AAD9AAoACwACAEEAhAAAAP0ACgALAAMAQQCiAAAA/QAKAAsABABBAEIAAAD9AAoACwAHAEEA ogAAAP0ACgALAAoAQQBCAAAA/QAKAAsADwBLAIQAAAD9AAoACwARAEEAQgAAAP0ACgALABIA QQBCAAAA/QAKAAwAAABBAKMAAAD9AAoADAACAEEAhQAAAP0ACgAMAAMAQQCjAAAA/QAKAAwA BABBAKMAAAD9AAoADAAHAEEAHQEAAP0ACgAMAAoAQQCjAAAA/QAKAAwADwBLAIUAAAD9AAoA DAARAEEAowAAAP0ACgAMABIAQQCjAAAA/QAKAA0AAABBAKwAAAD9AAoADQACAEEArAAAAP0A CgANAAMAQQCsAAAA/QAKAA0ABABBAKwAAAD9AAoADQAGAEEADgAAAP0ACgANAAcAQQAaAQAA /QAKAA0ACABBAKwAAAD9AAoADQAJAEEADgAAAP0ACgANAAoAQQCsAAAA/QAKAA0ADABBAKwA AAD9AAoADQANAEEADgAAAP0ACgANAA4AQQCsAAAA/QAKAA0ADwBLAHIBAAD9AAoADQAQAEEA rAAAAP0ACgANABEAQQCsAAAA/QAKAA0AEgBBAKwAAAD9AAoADQATAEEArAAAAP0ACgANABQA QwCsAAAA/QAKAA4AAABBAA8AAAD9AAoADgACAEEADwAAAP0ACgAOAAMAQQAPAAAA/QAKAA4A BABBAA8AAAD9AAoADgAFAEEAOAAAAP0ACgAOAAYAQQACAAAA/QAKAA4ABwBBAMEAAAD9AAoA DgAIAEEAEAAAAP0ACgAOAAkAQQACAAAA/QAKAA4ACgBBADgBAAD9AAoADgALAEEAOAAAAP0A CgAOAAwAQQDBAAAA/QAKAA4ADQBBAAIAAAD9AAoADgAOAEEAEAAAAP0ACgAOAA8ASwDBAAAA /QAKAA4AEABBADgBAAD9AAoADgARAEEADwAAAP0ACgAOABIAQQAPAAAA/QAKAA4AEwBBABAA AAD9AAoADgAUAEMAVQEAAAECBgAPAA8ASwD9AAoAEAAAAEEArQAAAP0ACgAQAAIAQQCtAAAA /QAKABAAAwBBAK0AAAD9AAoAEAAEAEEArQAAAP0ACgAQAAUAQQCtAAAA/QAKABAABwBBACMB AAD9AAoAEAAIAEEArQAAAP0ACgAQAAoAQQCtAAAA/QAKABAACwBBAK0AAAD9AAoAEAAMAEEA rQAAAP0ACgAQAA4AQQCtAAAA/QAKABAADwBLAK0AAAD9AAoAEAAQAEEArQAAAP0ACgAQABEA QQCtAAAA/QAKABAAEgBBAK0AAAD9AAoAEAATAEEArQAAAP0ACgAQABQAQwCtAAAA/QAKABEA AABBAMIAAAD9AAoAEQACAEEAwgAAAP0ACgARAAMAQQDCAAAA/QAKABEABABBAMIAAAD9AAoA EQAFAEEAwgAAAP0ACgARAAcAQQAkAQAA/QAKABEACABBAMIAAAD9AAoAEQAKAEEAwgAAAP0A CgARAAsAQQDCAAAA/QAKABEADABBAMIAAAD9AAoAEQAOAEEAwgAAAP0ACgARAA8ASwDCAAAA /QAKABEAEABBAMIAAAD9AAoAEQARAEEAwgAAAP0ACgARABIAQQDCAAAA/QAKABEAEwBBAMIA AAD9AAoAEQAUAEMAwgAAAP0ACgASAAAAQQDDAAAA/QAKABIAAgBBAMMAAAD9AAoAEgADAEEA wwAAAP0ACgASAAQAQQDDAAAA/QAKABIABQBBAMMAAAD9AAoAEgAHAEEAJQEAAP0ACgASAAgA QQDDAAAA/QAKABIACgBBAMMAAAD9AAoAEgALAEEAwwAAAP0ACgASAAwAQQDDAAAA/QAKABIA DgBBAMMAAAD9AAoAEgAPAEsAwwAAAP0ACgASABAAQQDDAAAA/QAKABIAEQBBAMMAAAD9AAoA EgATAEEAwwAAAP0ACgASABQAQwDDAAAA/QAKABMAAABBACQAAAD9AAoAEwACAEEARAAAAP0A CgATAAMAQQDEAAAA/QAKABMABABBACQAAAD9AAoAEwAFAEEAFAEAAP0ACgATAAcAQQAmAQAA /QAKABMACABBAEQAAAD9AAoAEwAKAEEARAAAAP0ACgATAAsAQQAUAQAA/QAKABMADABBAMQA AAD9AAoAEwAOAEEARAAAAP0ACgATAA8ASwDEAAAA/QAKABMAEABBAEQAAAD9AAoAEwARAEEA RwEAAP0ACgATABIAQQBHAQAA/QAKABMAEwBBAEQAAAD9AAoAEwAUAEMAAQEAAP0ACgAUAAAA QQBbAAAA/QAKABQAAgBBAEUAAAD9AAoAFAADAEEAWwAAAP0ACgAUAAQAQQBbAAAA/QAKABQA BwBBACcBAAD9AAoAFAAIAEEARQAAAP0ACgAUAA4AQQBFAAAAAQIGABQADwBLAP0ACgAUABMA QQBFAAAAAQIGABQAFABDAP0ACgAVAAAAQQBcAAAA/QAKABUAAgBBAEYAAAD9AAoAFQADAEEA XAAAAP0ACgAVAAcAQQAoAQAA/QAKABUACABBAEYAAAD9AAoAFQAOAEEARgAAAP0ACgAVABMA QQBGAAAAAQIGABUAFABDAP0ACgAWAAAAQQDFAAAA/QAKABYAAgBBAMUAAAD9AAoAFgADAEEA xQAAAP0ACgAWAAQAQQDFAAAA/QAKABYABQBBAMUAAAD9AAoAFgAHAEEAKQEAAP0ACgAWAAgA QQDFAAAA/QAKABYACgBBAMUAAAD9AAoAFgALAEEAxQAAAP0ACgAWAAwAQQDFAAAA/QAKABYA DgBBAMUAAAD9AAoAFgAPAEsAxQAAAP0ACgAWABAAQQDFAAAA/QAKABYAEQBBAMUAAAD9AAoA FgASAEEAxQAAAP0ACgAWABMAQQDFAAAA/QAKABYAFABDAMUAAAD9AAoAFwAAAEEAxgAAAP0A CgAXAAIAQQDGAAAA/QAKABcAAwBBAMYAAAD9AAoAFwAEAEEAxgAAAP0ACgAXAAUAQQDGAAAA /QAKABcABwBBACoBAAD9AAoAFwAIAEEAxgAAAP0ACgAXAAsAQQDGAAAA/QAKABcADABBAMYA AAD9AAoAFwAOAEEAxgAAAP0ACgAXAA8ASwDGAAAA/QAKABcAEABBAEABAAD9AAoAFwASAEEA xgAAAP0ACgAXABMAQQDGAAAA/QAKABcAFABDAMYAAAD9AAoAGAAAAEEAyAAAAP0ACgAYAAIA QQDIAAAA/QAKABgAAwBBAMgAAAD9AAoAGAAEAEEAyAAAAP0ACgAYAAUAQQDIAAAA/QAKABgA BwBBACsBAAD9AAoAGAAIAEEAyAAAAP0ACgAYAAoAQQDIAAAA/QAKABgACwBBAMgAAAD9AAoA GAAMAEEAyAAAAP0ACgAYAA4AQQDIAAAA/QAKABgADwBLAMgAAAD9AAoAGAAQAEEAyAAAAP0A CgAYABEAQQDIAAAA/QAKABgAEgBBAMgAAAD9AAoAGAATAEEAyAAAAP0ACgAYABQAQwDIAAAA /QAKABkAAABBAMcAAAD9AAoAGQACAEEAxwAAAP0ACgAZAAMAQQBdAAAA/QAKABkABABBAMcA AAD9AAoAGQAFAEEAxwAAAP0ACgAZAAcAQQAsAQAA/QAKABkACABBAMcAAAD9AAoAGQAKAEEA xwAAAP0ACgAZAAsAQQDHAAAA/QAKABkADABBAMcAAAD9AAoAGQAOAEEAxwAAAP0ACgAZAA8A SwBzAQAA/QAKABkAEABBAMcAAAD9AAoAGQARAEEAxwAAAP0ACgAZABIAQQDHAAAA/QAKABkA EwBBAMcAAAD9AAoAGQAUAEMAxwAAAP0ACgAaAAAAQQAlAAAA/QAKABoABABBACUAAAABAgYA GgAPAEsA/QAKABoAEQBBACUAAAD9AAoAGgASAEEAJQAAAAECBgAaABQAQwD9AAoAGwAAAEEA yQAAAP0ACgAbAAIAQQDNAAAA/QAKABsAAwBBAM0AAAD9AAoAGwAEAEEAyQAAAP0ACgAbAAUA QQDNAAAA/QAKABsABwBBAC0BAAD9AAoAGwAIAEEAzQAAAP0ACgAbAAoAQQDNAAAA/QAKABsA CwBBAM0AAAD9AAoAGwAMAEEAyQAAAP0ACgAbAA4AQQDNAAAA/QAKABsADwBLAMkAAAD9AAoA GwAQAEEAzQAAAP0ACgAbABEAQQDJAAAA/QAKABsAEgBBAMkAAAD9AAoAGwATAEEAzQAAAP0A CgAbABQAQwDNAAAA/QAKABwAAABBAFYBAAD9AAoAHAACAEEAzgAAAP0ACgAcAAMAQQDOAAAA /QAKABwABQBBAAIBAAD9AAoAHAAHAEEALgEAAP0ACgAcAAgAQQDOAAAA/QAKABwACwBBAAIB AAD9AAoAHAAOAEEAzgAAAAECBgAcAA8ASwD9AAoAHAATAEEAzgAAAP0ACgAcABQAQwACAQAA /QAKAB0AAABBAMoAAAD9AAoAHQACAEEAzwAAAP0ACgAdAAMAQQDPAAAA/QAKAB0ABABBAMoA AAD9AAoAHQAFAEEAAwEAAP0ACgAdAAcAQQAvAQAA/QAKAB0ACABBAM8AAAD9AAoAHQALAEEA AwEAAP0ACgAdAAwAQQCMAQAA/QAKAB0ADgBBAM8AAAD9AAoAHQAPAEsAygAAAP0ACgAdABEA QQDKAAAA/QAKAB0AEwBBAM8AAAD9AAoAHQAUAEMAAwEAAP0ACgAeAAAAQQBXAQAA/QAKAB4A AgBBANAAAAD9AAoAHgADAEEA0AAAAP0ACgAeAAUAQQAEAQAA/QAKAB4ABwBBADABAAD9AAoA HgAIAEEA0AAAAP0ACgAeAAsAQQAEAQAA/QAKAB4ADgBBANAAAAABAgYAHgAPAEsA/QAKAB4A EwBBANAAAAD9AAoAHgAUAEMABAEAAP0ACgAfAAAAQQDLAAAA/QAKAB8AAgBBAMsAAAD9AAoA HwADAEEA0QAAAP0ACgAfAAQAQQDLAAAA/QAKAB8ABQBBAMsAAAD9AAoAHwAHAEEAMQEAAP0A CgAfAAgAQQDLAAAA/QAKAB8ACgBBAMsAAAD9AAoAHwALAEEAywAAAP0ACgAfAAwAQQDLAAAA /QAKAB8ADgBBAMsAAAD9AAoAHwAPAEsAywAAAP0ACgAfABAAQQDLAAAA/QAKAB8AEQBBAMsA AAD9AAoAHwASAEEAywAAAP0ACgAfABMAQQDLAAAA/QAKAB8AFABDAMsAAAABAgYAIAAPAEsA AQIGACAAFABDAP0ACgAhAAAAQQAmAAAA/QAKACEAAgBBAK4AAAD9AAoAIQADAEEA0gAAAP0A CgAhAAQAQQAmAAAA/QAKACEABQBBAK4AAAD9AAoAIQAHAEEAIwEAAP0ACgAhAAgAQQCuAAAA /QAKACEACgBBAK4AAAD9AAoAIQALAEEArgAAAP0ACgAhAAwAQQCuAAAA/QAKACEADgBBAK4A AAD9AAoAIQAPAEsArgAAAP0ACgAhABAAQQCuAAAA/QAKACEAEQBBACYAAAD9AAoAIQASAEEA JgAAAP0ACgAhABMAQQCuAAAA/QAKACEAFABDAK4AAADXAEQAuhoAAGwCSAAUAQoB7gAYARgB CgEKATgAfgB+APwAGAEKAO4A7gDgAO4AhABsAO4A0gDuAO4ATADuAJYAxACWAO4AFAAIAhAA IgAAABUABAEAAAAAAAEPAAgCEAAjAAAAFQAEAQAAAAAAAQ8ACAIQACQAAAAVAAQBAAAAAAAB DwAIAhAAJQAAABUABAEAAAAAAAEPAAgCEAAmAAAAFQAEAQAAAAAAAQ8ACAIQACcAAAAVAAQB AAAAAAABDwAIAhAAKAAAABUABAEAAAAAAAEPAAgCEAApAAAAFQAEAQAAAAAAAQ8ACAIQACoA AAAVAAQBAAAAAAABDwAIAhAAKwAAABUABAEAAAAAAAEPAAgCEAAsAAAAFQAEAQAAAAAAAQ8A CAIQAC0AAAAVAAQBAAAAAAABDwAIAhAALgAAABUABAEAAAAAAAEPAAgCEAAvAAAAFQAEAQAA AAAAAQ8ACAIQADAAAAAVAAQBAAAAAAABDwAIAhAAMQAAABUABAEAAAAAAAEPAAgCEAAyAAAA FQAEAQAAAAAAAQ8ACAIQADMAAAAVAAQBAAAAAAABDwAIAhAANAAAABUABAEAAAAAAAEPAAgC EAA1AAAAFQAEAQAAAAAAAQ8ACAIQADYAAAAVAAQBAAAAAAABDwAIAhAANwAAABUABAEAAAAA AAEPAAgCEAA4AAAAFQAEAQAAAAAAAQ8ACAIQADkAAAAVAAQBAAAAAAABDwAIAhAAOgAAABUA BAEAAAAAAAEPAAgCEAA7AAAAFQAEAQAAAAAAAQ8ACAIQADwAAAAVAAQBAAAAAAABDwAIAhAA PQAAABUABAEAAAAAAAEPAAgCEAA+AAAAFQAEAQAAAAAAAQ8ACAIQAD8AAAAVAAQBAAAAAAAB DwAIAhAAQAAAABUABAEAAAAAAAEPAAgCEABBAAAAFQAEAQAAAAAAAQ8A/QAKACIAAABBACcA AAD9AAoAIgACAEEArwAAAP0ACgAiAAMAQQDTAAAA/QAKACIABABBACcAAAD9AAoAIgAFAEEA rwAAAP0ACgAiAAcAQQAkAQAA/QAKACIACABBAK8AAAD9AAoAIgAKAEEArwAAAP0ACgAiAAsA QQCvAAAA/QAKACIADABBAK8AAAD9AAoAIgAOAEEArwAAAP0ACgAiAA8ASwCvAAAA/QAKACIA EABBAK8AAAD9AAoAIgARAEEAJwAAAP0ACgAiABIAQQAnAAAA/QAKACIAEwBBAK8AAAD9AAoA IgAUAEMArwAAAP0ACgAjAAAAQQAoAAAA/QAKACMAAgBBALAAAAD9AAoAIwADAEEA1AAAAP0A CgAjAAQAQQAoAAAA/QAKACMABQBBALAAAAD9AAoAIwAHAEEAJQEAAP0ACgAjAAgAQQCwAAAA /QAKACMACgBBALAAAAD9AAoAIwALAEEAsAAAAP0ACgAjAAwAQQCwAAAA/QAKACMADgBBALAA AAD9AAoAIwAPAEsAsAAAAP0ACgAjABAAQQCwAAAA/QAKACMAEQBBACgAAAD9AAoAIwASAEEA KAAAAP0ACgAjABMAQQCwAAAA/QAKACMAFABDALAAAAD9AAoAJAAAAEEAKQAAAP0ACgAkAAIA QQBHAAAA/QAKACQAAwBBANUAAAD9AAoAJAAEAEEAKQAAAP0ACgAkAAUAQQAVAQAA/QAKACQA BwBBACYBAAD9AAoAJAAIAEEARwAAAP0ACgAkAAoAQQBHAAAA/QAKACQACwBBABUBAAD9AAoA JAAMAEEAdAEAAP0ACgAkAA4AQQBHAAAA/QAKACQADwBLAHQBAAD9AAoAJAAQAEEARwAAAP0A CgAkABEAQQApAAAA/QAKACQAEgBBACkAAAD9AAoAJAATAEEARwAAAP0ACgAkABQAQwAFAQAA /QAKACUAAABBACoAAAD9AAoAJQACAEEASAAAAP0ACgAlAAMAQQDWAAAA/QAKACUABABBACoA AAD9AAoAJQAHAEEAJwEAAP0ACgAlAAgAQQBIAAAA/QAKACUADgBBAEgAAAABAgYAJQAPAEsA /QAKACUAEwBBAEgAAAABAgYAJQAUAEMA/QAKACYAAABBAFgBAAD9AAoAJgACAEEASQAAAP0A CgAmAAMAQQDXAAAA/QAKACYABwBBACgBAAD9AAoAJgAIAEEASQAAAP0ACgAmAA4AQQBJAAAA /QAKACYAEwBBAEkAAAABAgYAJgAUAEMA/QAKACcAAABBACsAAAD9AAoAJwACAEEAsQAAAP0A CgAnAAMAQQDYAAAA/QAKACcABABBACsAAAD9AAoAJwAFAEEAsQAAAP0ACgAnAAcAQQApAQAA /QAKACcACABBALEAAAD9AAoAJwAKAEEAsQAAAP0ACgAnAAsAQQCxAAAA/QAKACcADABBALEA AAD9AAoAJwAOAEEAsQAAAP0ACgAnAA8ASwCxAAAA/QAKACcAEABBALEAAAD9AAoAJwARAEEA KwAAAP0ACgAnABIAQQArAAAA/QAKACcAEwBBALEAAAD9AAoAJwAUAEMAsQAAAP0ACgAoAAAA QQAsAAAA/QAKACgAAgBBALIAAAD9AAoAKAADAEEA2QAAAP0ACgAoAAQAQQAsAAAA/QAKACgA BQBBALIAAAD9AAoAKAAHAEEAKgEAAP0ACgAoAAgAQQCyAAAA/QAKACgACwBBALIAAAD9AAoA KAAMAEEAsgAAAP0ACgAoAA4AQQCyAAAA/QAKACgADwBLALIAAAD9AAoAKAAQAEEAsgAAAP0A CgAoABMAQQCyAAAA/QAKACgAFABDALIAAAD9AAoAKQAAAEEALQAAAP0ACgApAAIAQQC0AAAA /QAKACkAAwBBANsAAAD9AAoAKQAEAEEALQAAAP0ACgApAAUAQQC0AAAA/QAKACkABwBBACsB AAD9AAoAKQAIAEEAtAAAAP0ACgApAAoAQQC0AAAA/QAKACkACwBBALQAAAD9AAoAKQAMAEEA tAAAAP0ACgApAA4AQQC0AAAA/QAKACkADwBLALQAAAD9AAoAKQAQAEEAtAAAAP0ACgApABEA QQAtAAAA/QAKACkAEgBBAC0AAAD9AAoAKQATAEEAtAAAAP0ACgApABQAQwC0AAAA/QAKACoA AABBAC4AAAD9AAoAKgACAEEAswAAAP0ACgAqAAMAQQDaAAAA/QAKACoABABBAC4AAAD9AAoA KgAFAEEAswAAAP0ACgAqAAcAQQAsAQAA/QAKACoACABBALMAAAD9AAoAKgAKAEEAswAAAP0A CgAqAAsAQQCzAAAA/QAKACoADABBALMAAAD9AAoAKgAOAEEAswAAAP0ACgAqAA8ASwB1AQAA /QAKACoAEABBALMAAAD9AAoAKgARAEEALgAAAP0ACgAqABIAQQAuAAAA/QAKACoAEwBBALMA AAD9AAoAKgAUAEMAswAAAP0ACgArAAAAQQAvAAAA/QAKACsABABBAC8AAAABAgYAKwAPAEsA /QAKACsAEQBBAC8AAAD9AAoAKwASAEEALwAAAAECBgArABQAQwD9AAoALAAAAEEAMAAAAP0A CgAsAAIAQQBKAAAA/QAKACwAAwBBANwAAAD9AAoALAAEAEEAMAAAAP0ACgAsAAUAQQBKAAAA /QAKACwABwBBAC0BAAD9AAoALAAIAEEASgAAAP0ACgAsAAoAQQBKAAAA/QAKACwACwBBAEoA AAD9AAoALAAMAEEAdgEAAP0ACgAsAA4AQQBKAAAA/QAKACwADwBLAHYBAAD9AAoALAAQAEEA SgAAAP0ACgAsABEAQQAwAAAA/QAKACwAEgBBADAAAAD9AAoALAATAEEASgAAAP0ACgAsABQA QwBKAAAA/QAKAC0AAABBAFkBAAD9AAoALQACAEEASwAAAP0ACgAtAAMAQQDdAAAA/QAKAC0A BQBBAAYBAAD9AAoALQAHAEEALgEAAP0ACgAtAAgAQQBLAAAA/QAKAC0ACwBBAAYBAAD9AAoA LQAOAEEASwAAAAECBgAtAA8ASwD9AAoALQATAEEASwAAAP0ACgAtABQAQwAGAQAA/QAKAC4A AABBAF4AAAD9AAoALgACAEEATAAAAP0ACgAuAAMAQQDeAAAA/QAKAC4ABABBAF4AAAD9AAoA LgAFAEEABwEAAP0ACgAuAAcAQQAvAQAA/QAKAC4ACABBAEwAAAD9AAoALgALAEEABwEAAP0A CgAuAAwAQQCOAQAA/QAKAC4ADgBBAEwAAAD9AAoALgAPAEsAdwEAAP0ACgAuABEAQQBeAAAA /QAKAC4AEgBBAF4AAAD9AAoALgATAEEATAAAAP0ACgAuABQAQwAHAQAA/QAKAC8AAABBAFoB AAD9AAoALwACAEEATQAAAP0ACgAvAAMAQQDfAAAA/QAKAC8ABQBBAAgBAAD9AAoALwAHAEEA MAEAAP0ACgAvAAgAQQBNAAAA/QAKAC8ACwBBAAgBAAD9AAoALwAOAEEATQAAAAECBgAvAA8A SwD9AAoALwATAEEATQAAAP0ACgAvABQAQwAIAQAA/QAKADAAAABBAF8AAAD9AAoAMAACAEEA tQAAAP0ACgAwAAMAQQDgAAAA/QAKADAABABBAF8AAAD9AAoAMAAFAEEAtQAAAP0ACgAwAAcA QQAxAQAA/QAKADAACABBALUAAAD9AAoAMAAKAEEAtQAAAP0ACgAwAAsAQQC1AAAA/QAKADAA DABBALUAAAD9AAoAMAAOAEEAtQAAAP0ACgAwAA8ASwC1AAAA/QAKADAAEABBALUAAAD9AAoA MAARAEEAXwAAAP0ACgAwABIAQQBfAAAA/QAKADAAEwBBALUAAAD9AAoAMAAUAEMAtQAAAAEC BgAxABQAQwD9AAoAMgAAAEEAYAAAAP0ACgAyAAIAQQC+AAAA/QAKADIAAwBBAL4AAAD9AAoA MgAEAEEAYAAAAP0ACgAyAAUAQQC+AAAA/QAKADIABwBBACMBAAD9AAoAMgAIAEEAvgAAAP0A CgAyAAsAQQC+AAAA/QAKADIADABBAL4AAAD9AAoAMgAPAEsAvgAAAP0ACgAyABEAQQBgAAAA /QAKADIAEgBBAGAAAAD9AAoAMwAAAEEAYQAAAP0ACgAzAAIAQQC/AAAA/QAKADMAAwBBAL8A AAD9AAoAMwAEAEEAYQAAAP0ACgAzAAUAQQC/AAAA/QAKADMABwBBACQBAAD9AAoAMwAIAEEA vwAAAP0ACgAzAAsAQQC/AAAA/QAKADMADABBAL8AAAD9AAoAMwAPAEsAvwAAAP0ACgAzABEA QQBhAAAA/QAKADMAEgBBAGEAAAD9AAoANAAAAEEAYgAAAP0ACgA0AAIAQQDAAAAA/QAKADQA AwBBAMAAAAD9AAoANAAEAEEAYgAAAP0ACgA0AAUAQQDAAAAA/QAKADQABwBBACUBAAD9AAoA NAAIAEEAwAAAAP0ACgA0AAsAQQDAAAAA/QAKADQADABBAMAAAAD9AAoANAAPAEsAwAAAAP0A CgA0ABEAQQBiAAAA/QAKADUAAABBAGMAAAD9AAoANQACAEEATgAAAP0ACgA1AAMAQQB9AAAA /QAKADUABABBAGMAAAD9AAoANQAFAEEADQEAAP0ACgA1AAcAQQAmAQAA/QAKADUACABBAE4A AAD9AAoANQALAEEADQEAAP0ACgA1AAwAQQB9AAAA/QAKADUADwBLAH0AAAD9AAoANQARAEEA YwAAAP0ACgA1ABIAQQBjAAAA/QAKADYAAABBADIAAAD9AAoANgACAEEATwAAAP0ACgA2AAMA QQBuAAAA/QAKADYABABBADIAAAD9AAoANgAHAEEAJwEAAP0ACgA2AAgAQQBPAAAAAQIGADYA DwBLAP0ACgA3AAAAQQBbAQAA/QAKADcAAgBBAFAAAAD9AAoANwADAEEAbwAAAP0ACgA3AAcA QQAoAQAA/QAKADcACABBAFAAAAABAgYANwAPAEsA/QAKADgAAABBADMAAAD9AAoAOAACAEEA fgAAAP0ACgA4AAMAQQB+AAAA/QAKADgABABBADMAAAD9AAoAOAAFAEEAfgAAAP0ACgA4AAcA QQApAQAA/QAKADgACABBAH4AAAD9AAoAOAALAEEAfgAAAP0ACgA4AAwAQQB+AAAA/QAKADgA DwBLAH4AAAD9AAoAOAARAEEAMwAAAP0ACgA4ABIAQQAzAAAA/QAKADkAAABBADQAAAD9AAoA OQACAEEAfwAAAP0ACgA5AAMAQQB/AAAA/QAKADkABABBADQAAAD9AAoAOQAFAEEAfwAAAP0A CgA5AAcAQQAqAQAA/QAKADkACABBAH8AAAD9AAoAOQALAEEAfwAAAP0ACgA5AAwAQQB/AAAA /QAKADkADwBLAH8AAAD9AAoAOQASAEEANAAAAP0ACgA6AAAAQQA1AAAA/QAKADoAAgBBAIEA AAD9AAoAOgADAEEAgQAAAP0ACgA6AAQAQQA1AAAA/QAKADoABQBBAIEAAAD9AAoAOgAHAEEA KwEAAP0ACgA6AAgAQQCBAAAA/QAKADoACwBBAIEAAAD9AAoAOgAMAEEAgQAAAP0ACgA6AA8A SwCBAAAA/QAKADoAEQBBADUAAAD9AAoAOgASAEEANQAAAP0ACgA7AAAAQQA2AAAA/QAKADsA AgBBAIAAAAD9AAoAOwADAEEAcAAAAP0ACgA7AAQAQQA2AAAA/QAKADsABQBBAIAAAAD9AAoA OwAHAEEALAEAAP0ACgA7AAgAQQCAAAAA/QAKADsACwBBAIAAAAD9AAoAOwAMAEEAgAAAAP0A CgA7AA8ASwB8AQAA/QAKADsAEQBBADYAAAD9AAoAOwASAEEANgAAAP0ACgA8AAAAQQASAAAA /QAKADwABABBABIAAAABAgYAPAAPAEsA/QAKADwAEQBBABIAAAD9AAoAPAASAEEAEgAAAP0A CgA9AAAAQQATAAAA/QAKAD0AAgBBAHEAAAD9AAoAPQADAEEAcQAAAP0ACgA9AAQAQQATAAAA /QAKAD0ABQBBAHEAAAD9AAoAPQAHAEEALQEAAP0ACgA9AAgAQQBxAAAA/QAKAD0ACwBBAHEA AAD9AAoAPQAMAEEAfQEAAP0ACgA9AA8ASwB9AQAA/QAKAD0AEQBBABMAAAD9AAoAPQASAEEA EwAAAP0ACgA+AAAAQQBcAQAA/QAKAD4AAgBBAHIAAAD9AAoAPgADAEEAcgAAAP0ACgA+AAUA QQAOAQAA/QAKAD4ABwBBAC4BAAD9AAoAPgAIAEEAcgAAAP0ACgA+AAsAQQAOAQAAAQIGAD4A DwBLAP0ACgA/AAAAQQAUAAAA/QAKAD8AAgBBAHMAAAD9AAoAPwADAEEAcwAAAP0ACgA/AAQA QQAUAAAA/QAKAD8ABQBBAA8BAAD9AAoAPwAHAEEALwEAAP0ACgA/AAgAQQBzAAAA/QAKAD8A CwBBAA8BAAD9AAoAPwAMAEEAkAEAAP0ACgA/AA8ASwB+AQAA/QAKAD8AEQBBABQAAAD9AAoA QAAAAEEAXQEAAP0ACgBAAAIAQQB0AAAA/QAKAEAAAwBBAHQAAAD9AAoAQAAFAEEAEAEAAP0A CgBAAAcAQQAwAQAA/QAKAEAACABBAHQAAAD9AAoAQAALAEEAEAEAAAECBgBAAA8ASwD9AAoA QQAAAEEAFQAAAP0ACgBBAAIAQQCCAAAA/QAKAEEAAwBBAHUAAAD9AAoAQQAEAEEAFQAAAP0A CgBBAAUAQQCCAAAA/QAKAEEABwBBADEBAAD9AAoAQQAIAEEAggAAAP0ACgBBAAsAQQCCAAAA /QAKAEEADABBAIIAAAD9AAoAQQAPAEsAggAAAP0ACgBBABEAQQAVAAAA/QAKAEEAEgBBABUA AADXAEQAzhYAAGwC7gDuAO4AhABsAO4AxADuAO4ATADuAJYA0gCWAO4ACgCoAKgAmgCoAF4A UACoAJoAqACoAEIAqABsAJoAbAAIAhAAQwAAABUABAEAAAAAAAEPAAgCEABEAAAAFQAEAQAA AAAAAQ8ACAIQAEUAAAAVAAQBAAAAAAABDwAIAhAARgAAABUABAEAAAAAAAEPAAgCEABHAAAA FQAEAQAAAAAAAQ8ACAIQAEgAAAAVAAQBAAAAAAABDwAIAhAASQAAABUABAEAAAAAAAEPAAgC EABKAAAAFQAEAQAAAAAAAQ8ACAIQAEsAAAAVAAQBAAAAAAABDwAIAhAATAAAABUABAEAAAAA AAEPAAgCEABNAAAAFQAEAQAAAAAAAQ8ACAIQAE4AAAAVAAQBAAAAAAABDwAIAhAATwAAABUA BAEAAAAAAAEPAAgCEABQAAAAFQAEAQAAAAAAAQ8ACAIQAFEAAAAVAAQBAAAAAAABDwAIAhAA UgAAABUABAEAAAAAAAEPAAgCEABTAAAAFQAEAQAAAAAAAQ8ACAIQAFQAAAAVAAQBAAAAAAAB DwAIAhAAVQAAABUABAEAAAAAAAEPAAgCEABWAAAAFQAEAQAAAAAAAQ8ACAIQAFcAAAAVAAQB AAAAAAABDwAIAhAAWAAAABUAQAEAAAAAAAEPAAgCEABZAAAAFQBAAQAAAAAAAQ8ACAIQAFoA AAAVAAgCAAAAAAABDwAIAhAAWwAAABUABAEAAAAAAAEPAAgCEABcAAAAFQAEAQAAAAAAAQ8A CAIQAF0AAAAVAAQBAAAAAAABDwAIAhAAXgAAABUABAEAAAAAAAEPAAgCEABfAAAAFQAEAQAA AAAAAQ8ACAIQAGAAAAAPAAQBAAAAAAABDwAIAhAAYQAAAA8ABAEAAAAAAAEPAP0ACgBDAAAA QQAWAAAA/QAKAEMAAgBBALYAAAD9AAoAQwADAEEA4QAAAP0ACgBDAAQAQQAWAAAA/QAKAEMA BQBBALYAAAD9AAoAQwAHAEEAIwEAAP0ACgBDAAgAQQC2AAAA/QAKAEMACgBBALYAAAD9AAoA QwALAEEAtgAAAP0ACgBDAAwAQQC2AAAA/QAKAEMADgBBALYAAAD9AAoAQwAPAEsAtgAAAP0A CgBDABAAQQC2AAAA/QAKAEMAEQBBABYAAAD9AAoAQwASAEEAFgAAAP0ACgBDABMAQQC2AAAA /QAKAEMAFABDALYAAAD9AAoARAAAAEEAFwAAAP0ACgBEAAIAQQC3AAAA/QAKAEQAAwBBAOIA AAD9AAoARAAEAEEAFwAAAP0ACgBEAAUAQQC3AAAA/QAKAEQABwBBACQBAAD9AAoARAAIAEEA twAAAP0ACgBEAAoAQQC3AAAA/QAKAEQACwBBALcAAAD9AAoARAAMAEEAtwAAAP0ACgBEAA4A QQC3AAAAAQIGAEQADwBLAP0ACgBEABAAQQC3AAAA/QAKAEQAEQBBABcAAAD9AAoARAASAEEA FwAAAP0ACgBEABMAQQC3AAAA/QAKAEQAFABDALcAAAD9AAoARQAAAEEAGAAAAP0ACgBFAAIA QQC4AAAA/QAKAEUAAwBBAOMAAAD9AAoARQAEAEEAGAAAAP0ACgBFAAUAQQC4AAAA/QAKAEUA BwBBACUBAAD9AAoARQAIAEEAuAAAAP0ACgBFAAoAQQC4AAAA/QAKAEUACwBBALgAAAD9AAoA RQAMAEEAuAAAAP0ACgBFAA4AQQC4AAAA/QAKAEUADwBLALgAAAD9AAoARQAQAEEAuAAAAP0A CgBFABEAQQAYAAAA/QAKAEUAEwBBALgAAAD9AAoARQAUAEMAuAAAAP0ACgBGAAAAQQAZAAAA /QAKAEYAAgBBAGQAAAD9AAoARgADAEEA5AAAAP0ACgBGAAQAQQAZAAAA/QAKAEYABQBBABYB AAD9AAoARgAHAEEAJgEAAP0ACgBGAAgAQQBkAAAA/QAKAEYACgBBAGQAAAD9AAoARgALAEEA FgEAAP0ACgBGAAwAQQB4AQAA/QAKAEYADgBBAGQAAAD9AAoARgAPAEsAeAEAAP0ACgBGABAA QQBkAAAA/QAKAEYAEQBBABkAAAD9AAoARgASAEEAGQAAAP0ACgBGABMAQQBkAAAA/QAKAEYA FABDAAkBAAD9AAoARwAAAEEAGgAAAP0ACgBHAAIAQQBlAAAA/QAKAEcAAwBBAOUAAAD9AAoA RwAEAEEAGgAAAP0ACgBHAAcAQQAnAQAA/QAKAEcACABBAGUAAAD9AAoARwAOAEEAZQAAAAEC BgBHAA8ASwD9AAoARwATAEEAZQAAAAECBgBHABQAQwD9AAoASAAAAEEAXgEAAP0ACgBIAAIA QQBmAAAA/QAKAEgAAwBBAOYAAAD9AAoASAAHAEEAKAEAAP0ACgBIAAgAQQBmAAAA/QAKAEgA DgBBAGYAAAD9AAoASAATAEEAZgAAAAECBgBIABQAQwD9AAoASQAAAEEAGwAAAP0ACgBJAAIA QQC5AAAA/QAKAEkAAwBBAOcAAAD9AAoASQAEAEEAGwAAAP0ACgBJAAUAQQC5AAAA/QAKAEkA BwBBACkBAAD9AAoASQAIAEEAuQAAAP0ACgBJAAoAQQC5AAAA/QAKAEkACwBBALkAAAD9AAoA SQAMAEEAuQAAAP0ACgBJAA4AQQC5AAAA/QAKAEkADwBLALkAAAD9AAoASQAQAEEAuQAAAP0A CgBJABEAQQAbAAAA/QAKAEkAEgBBABsAAAD9AAoASQATAEEAuQAAAP0ACgBJABQAQwC5AAAA /QAKAEoAAABBABwAAAD9AAoASgACAEEAugAAAP0ACgBKAAMAQQDoAAAA/QAKAEoABABBABwA AAD9AAoASgAFAEEAugAAAP0ACgBKAAcAQQAqAQAA/QAKAEoACABBALoAAAD9AAoASgALAEEA ugAAAP0ACgBKAAwAQQC6AAAA/QAKAEoADgBBALoAAAD9AAoASgAPAEsAugAAAP0ACgBKABAA QQC6AAAA/QAKAEoAEgBBABwAAAD9AAoASgATAEEAugAAAP0ACgBKABQAQwC6AAAA/QAKAEsA AABBAB0AAAD9AAoASwACAEEAvAAAAP0ACgBLAAMAQQDqAAAA/QAKAEsABABBAB0AAAD9AAoA SwAFAEEAvAAAAP0ACgBLAAcAQQArAQAA/QAKAEsACABBALwAAAD9AAoASwAKAEEAvAAAAP0A CgBLAAsAQQC8AAAA/QAKAEsADABBALwAAAD9AAoASwAOAEEAvAAAAP0ACgBLAA8ASwC8AAAA /QAKAEsAEABBALwAAAD9AAoASwARAEEAHQAAAP0ACgBLABIAQQAdAAAA/QAKAEsAEwBBALwA AAD9AAoASwAUAEMAvAAAAP0ACgBMAAAAQQAeAAAA/QAKAEwAAgBBALsAAAD9AAoATAADAEEA 6QAAAP0ACgBMAAQAQQAeAAAA/QAKAEwABQBBALsAAAD9AAoATAAHAEEALAEAAP0ACgBMAAgA QQC7AAAA/QAKAEwACgBBALsAAAD9AAoATAALAEEAuwAAAP0ACgBMAAwAQQC7AAAA/QAKAEwA DgBBALsAAAD9AAoATAAPAEsAeQEAAP0ACgBMABAAQQC7AAAA/QAKAEwAEQBBAB4AAAD9AAoA TAASAEEAHgAAAP0ACgBMABMAQQC7AAAA/QAKAEwAFABDALsAAAD9AAoATQAAAEEAHwAAAP0A CgBNAAQAQQAfAAAAAQIGAE0ADwBLAP0ACgBNABEAQQAfAAAA/QAKAE0AEgBBAB8AAAABAgYA TQAUAEMA/QAKAE4AAABBACAAAAD9AAoATgACAEEAZwAAAP0ACgBOAAMAQQDrAAAA/QAKAE4A BABBACAAAAD9AAoATgAFAEEAZwAAAP0ACgBOAAcAQQAtAQAA/QAKAE4ACABBAGcAAAD9AAoA TgAKAEEAZwAAAP0ACgBOAAsAQQBnAAAA/QAKAE4ADABBAHoBAAD9AAoATgAOAEEAZwAAAP0A CgBOAA8ASwB6AQAA/QAKAE4AEABBAGcAAAD9AAoATgARAEEAIAAAAP0ACgBOABIAQQAgAAAA /QAKAE4AEwBBAGcAAAD9AAoATgAUAEMAZwAAAP0ACgBPAAAAQQBfAQAA/QAKAE8AAgBBAGgA AAD9AAoATwADAEEA7AAAAP0ACgBPAAUAQQAKAQAA/QAKAE8ABwBBAC4BAAD9AAoATwAIAEEA aAAAAP0ACgBPAAsAQQAKAQAA/QAKAE8ADgBBAGgAAAABAgYATwAPAEsA/QAKAE8AEwBBAGgA AAD9AAoATwAUAEMACgEAAP0ACgBQAAAAQQAhAAAA/QAKAFAAAgBBAGkAAAD9AAoAUAADAEEA 7QAAAP0ACgBQAAQAQQAhAAAA/QAKAFAABQBBAAsBAAD9AAoAUAAHAEEALwEAAP0ACgBQAAgA QQBpAAAA/QAKAFAACwBBAAsBAAD9AAoAUAAMAEEAjwEAAP0ACgBQAA4AQQBpAAAA/QAKAFAA DwBLAHsBAAD9AAoAUAARAEEAIQAAAP0ACgBQABMAQQBpAAAA/QAKAFAAFABDAAsBAAD9AAoA UQAAAEEAYAEAAP0ACgBRAAIAQQBqAAAA/QAKAFEAAwBBAGwAAAD9AAoAUQAFAEEADAEAAP0A CgBRAAcAQQAwAQAA/QAKAFEACABBAGoAAAD9AAoAUQALAEEADAEAAP0ACgBRAA4AQQBqAAAA AQIGAFEADwBLAP0ACgBRABMAQQBqAAAA/QAKAFEAFABDAAwBAAD9AAoAUgAAAEEAIgAAAP0A CgBSAAIAQQC9AAAA/QAKAFIAAwBBAG0AAAD9AAoAUgAEAEEAIgAAAP0ACgBSAAUAQQC9AAAA /QAKAFIABwBBADEBAAD9AAoAUgAIAEEAvQAAAP0ACgBSAAoAQQC9AAAA/QAKAFIACwBBAL0A AAD9AAoAUgAMAEEAvQAAAP0ACgBSAA4AQQC9AAAA/QAKAFIADwBLAL0AAAD9AAoAUgAQAEEA vQAAAP0ACgBSABEAQQAiAAAA/QAKAFIAEgBBACIAAAD9AAoAUgATAEEAvQAAAP0ACgBSABQA QwC9AAAAAQIGAFMAFABEAP0ACgBUAAAAQQARAAAA/QAKAFQAAgBBAIEBAAD9AAoAVAADAEEA ggEAAP0ACgBUAAQAQQCBAQAA/QAKAFQABQBBAIEBAAD9AAoAVAAGAEEAgQEAAP0ACgBUAAcA QQCDAQAA/QAKAFQACABDAIEBAAD9AAoAVAAJAEMAgQEAAP0ACgBUAAoAQwCBAQAA/QAKAFQA CwBDAIEBAAD9AAoAVAAMAEEAzAAAAP0ACgBUAA0AQwCBAQAA/QAKAFQADgBDAIEBAAD9AAoA VAAPAEMAgQEAAP0ACgBUABAAQQARAAAA/QAKAFQAEQBDAIEBAAD9AAoAVAASAEMAgQEAAP0A CgBUABMAQwCBAQAA/QAKAFQAFABDAIEBAAABAgYAVQAUAA8AAQIGAFYAFAAPAAECBgBXABQA DwD9AAoAWAAAAEIAbwEAAP0ACgBYAAEAQgBhAQAA/QAKAFgAAgBCAHABAAD9AAoAWQACAEIA BQAAAP0ACgBZAAMAQgADAAAA/QAKAFkABABCAAcAAAD9AAoAWQAFAEIA/QAAAP0ACgBZAAYA QgAyAQAA/QAKAFkABwBCABcBAAD9AAoAWQAIAEIABgAAAP0ACgBZAAkAQgA0AQAA/QAKAFkA CgBCADUBAAD9AAoAWQALAEIAOQEAAP0ACgBZAAwAQgA8AQAA/QAKAFkADQBCADsBAAD9AAoA WQAOAEIABAAAAP0ACgBZAA8AQgA9AQAA/QAKAFkAEABCAD4BAAD9AAoAWQARAEIAQQEAAP0A CgBZABIAQgBFAQAA/QAKAFkAEwBCAEgBAAD9AAoAWQAUAEIAbgEAAP0ACgBaAAAAQQChAAAA /QAKAFoAAQBBAGIBAAD9AAoAWgACAEEAoQAAAP0ACgBaAAMAQQCNAAAA/QAKAFoABABBAPwA AAD9AAoAWgAFAEEA/gAAAP0ACgBaAAYAQQAxAAAA/QAKAFoABwBBABwBAAD9AAoAWgAIAEEA CAAAAP0ACgBaAAkAQQAxAAAA/QAKAFoACgBBAAgAAAD9AAoAWgALAEEA/gAAAP0ACgBaAAwA SACNAQAA/QAKAFoADQBBADEAAAD9AAoAWgAOAEEAOQAAAP0ACgBaAA8ASwCDAAAA/QAKAFoA EABBAD8BAAD9AAoAWgARAEEA/AAAAP0ACgBaABIAQQD8AAAA/QAKAFoAFAAPAFABAAD9AAoA WwAAAEEAgwAAAP0ACgBbAAEAQQCAAQAA/QAKAFsAAgBBAIMAAAD9AAoAWwADAEEAjgAAAP0A CgBbAAUAQQD/AAAA/QAKAFsABgBBACMAAAD9AAoAWwAHAEEAHgEAAP0ACgBbAAgAQQAJAAAA /QAKAFsACQBBACMAAAD9AAoAWwAKAEEACgAAAP0ACgBbAAsAQQD/AAAA/QAKAFsADQBBACMA AAD9AAoAWwAOAEEA8QAAAP0ACgBbABEAQQBCAQAA/QAKAFsAFAAPAFEBAAD9AAoAXAAAAEEA jQAAAP0ACgBcAAEAQQBjAQAA/QAKAFwAAwBBAI8AAAD9AAoAXAAFAEEAgwAAAP0ACgBcAAcA QQAbAQAA/QAKAFwACABBAAoAAAD9AAoAXAAKAEEACwAAAP0ACgBcAAsAQQCDAAAA/QAKAFwA DgBBAPIAAAABAgYAXAAPAEsA/QAKAFwAFAAPAEIBAAD9AAoAXQAAAEEAjgAAAP0ACgBdAAEA QQBjAQAA/QAKAF0AAwBBAJAAAAD9AAoAXQAFAEEAEQEAAP0ACgBdAAcAQQAiAQAA/QAKAF0A CABBAAsAAAD9AAoAXQAKAEEANgEAAP0ACgBdAAsAQQARAQAA/QAKAF0ADgBBAPMAAAD9AAoA XQAUAEEAOQAAAP0ACgBeAAAAQQCPAAAA/QAKAF4AAQBBAGMBAAD9AAoAXgADAEEAkQAAAP0A CgBeAAUAQQAAAQAA/QAKAF4ABwBBADMBAAD9AAoAXgAKAEEANwEAAP0ACgBeAAsAQQAAAQAA /QAKAF4ADgBBAPQAAAD9AAoAXwAAAEEAkAAAAP0ACgBfAAEAQQBjAQAA/QAKAF8AAwBBAJIA AAD9AAoAXwAOAEEA8AAAAP0ACgBgAAAAQQCRAAAA/QAKAGAAAQBBAGMBAAD9AAoAYAADAEEA kwAAAP0ACgBgAA4AQQA6AAAA/QAKAGEAAABBAJIAAAD9AAoAYQABAEEAYwEAAP0ACgBhAAMA QQCUAAAA/QAKAGEADgBBAPUAAADXAEIAThUAAFgC7gDqAOAA7gCEAGwA7gDSAO4A7gBMAO4A lgDEAJYA7gAKABgBCgAKAAoAKgAKARgB0gCWAIwAcAA4ADgACAIQAGIAAAAPAAQBAAAAAAAB DwAIAhAAYwAAAA8ABAEAAAAAAAEPAAgCEABkAAAADwAEAQAAAAAAAQ8ACAIQAGUAAAAPAAQB AAAAAAABDwAIAhAAZgAAAA8ABAEAAAAAAAEPAAgCEABnAAAADwAEAQAAAAAAAQ8ACAIQAGgA AAAPAAQBAAAAAAABDwAIAhAAaQAAAA8ABAEAAAAAAAEPAAgCEABqAAAADwAEAQAAAAAAAQ8A CAIQAGsAAAAPAAQBAAAAAAABDwAIAhAAbAAAAA8ABAEAAAAAAAEPAAgCEABtAAAADwAEAQAA AAAAAQ8ACAIQAG4AAAAPAAQBAAAAAAABDwAIAhAAbwAAAA8ABAEAAAAAAAEPAAgCEABwAAAA BAAEAQAAAAAAAQ8ACAIQAHEAAAAEAAQBAAAAAAABDwAIAhAAcgAAAAQABAEAAAAAAAEPAAgC EABzAAAABAAEAQAAAAAAAQ8ACAIQAHQAAAAEAAQBAAAAAAABDwAIAhAAdQAAAAQABAEAAAAA AAEPAAgCEAB2AAAABAAEAQAAAAAAAQ8ACAIQAHcAAAAEAAQBAAAAAAABDwAIAhAAeAAAAAQA BAEAAAAAAAEPAAgCEAB5AAAABAAEAQAAAAAAAQ8ACAIQAHoAAAAEAAQBAAAAAAABDwAIAhAA ewAAAAQABAEAAAAAAAEPAAgCEAB8AAAABAAEAQAAAAAAAQ8ACAIQAH0AAAAEAAQBAAAAAAAB DwAIAhAAfgAAAAQABAEAAAAAAAEPAAgCEAB/AAAABAAEAQAAAAAAAQ8ACAIQAIAAAAAQAAQB AAAAAAABDwAIAhAAgQAAABAABAEAAAAAAAEPAP0ACgBiAAAAQQCTAAAA/QAKAGIAAQBBAGMB AAD9AAoAYgADAEEAlQAAAP0ACgBiAA4AQQD2AAAA/QAKAGMAAABBAJQAAAD9AAoAYwABAEEA YwEAAP0ACgBjAAMAQQB2AAAA/QAKAGMADgBBAPcAAAD9AAoAZAAAAEEAlQAAAP0ACgBkAAEA QQBjAQAA/QAKAGQAAwBBAHcAAAD9AAoAZAAOAEEA+AAAAP0ACgBlAAAAQQB2AAAA/QAKAGUA AQBBAGMBAAD9AAoAZQADAEEAeAAAAP0ACgBlAA4AQQD5AAAA/QAKAGYAAABBAHcAAAD9AAoA ZgABAEEAYwEAAP0ACgBmAAMAQQB5AAAA/QAKAGYADgBBADsAAAD9AAoAZwAAAEEAeAAAAP0A CgBnAAEAQQBjAQAA/QAKAGcAAwBBAHoAAAD9AAoAaAAAAEEAeQAAAP0ACgBoAAEAQQBjAQAA /QAKAGgAAwBBAHsAAAD9AAoAaQAAAEEAegAAAP0ACgBpAAEAQQBjAQAA/QAKAGkAAwBBAHwA AAD9AAoAagAAAEEAewAAAP0ACgBqAAEAQQBjAQAA/QAKAGoAAwBBADwAAAD9AAoAawAAAEEA fAAAAP0ACgBrAAEAQQBjAQAA/QAKAGsAAwBBAD0AAAD9AAoAbAAAAEEAPAAAAP0ACgBsAAEA QQBjAQAA/QAKAGwAAwBBAD4AAAD9AAoAbQAAAEEAPQAAAP0ACgBtAAEAQQBjAQAA/QAKAG0A AwBBAD8AAAD9AAoAbgAAAEEAPgAAAP0ACgBuAAEAQQBjAQAA/QAKAG4AAwBBAEAAAAD9AAoA bwAAAEEAPwAAAP0ACgBvAAEAQQBjAQAA/QAKAG8AAwBBAEEAAAD9AAoAcAAAAEEAQAAAAP0A CgBwAAEAQQBjAQAA/QAKAHAAAwBBAJYAAAD9AAoAcQAAAEEAQQAAAP0ACgBxAAEAQQBjAQAA /QAKAHEAAwBBAJcAAAD9AAoAcgAAAEEAlgAAAP0ACgByAAEAQQBjAQAA/QAKAHIAAwBBAJgA AAD9AAoAcwAAAEEAlwAAAP0ACgBzAAEAQQBjAQAA/QAKAHMAAwBBAJkAAAD9AAoAdAAAAEEA mAAAAP0ACgB0AAEAQQBjAQAA/QAKAHQAAwBBAJoAAAD9AAoAdQAAAEEAmQAAAP0ACgB1AAEA QQBjAQAA/QAKAHUAAwBBAJsAAAD9AAoAdgAAAEEAmgAAAP0ACgB2AAEAQQBjAQAA/QAKAHYA AwBBAJwAAAD9AAoAdwAAAEEAmwAAAP0ACgB3AAEAQQBjAQAA/QAKAHcAAwBBAJ0AAAD9AAoA eAAAAEEAnAAAAP0ACgB4AAEAQQBjAQAA/QAKAHgAAwBBAJ4AAAD9AAoAeQAAAEEAnQAAAP0A CgB5AAEAQQBjAQAA/QAKAHkAAwBBAJ8AAAD9AAoAegAAAEEAngAAAP0ACgB6AAEAQQBjAQAA /QAKAHoAAwBBAKAAAAD9AAoAewAAAEEAnwAAAP0ACgB7AAEAQQBjAQAA/QAKAHsAAwBBAKQA AAD9AAoAfAAAAEEAoAAAAP0ACgB8AAEAQQBjAQAA/QAKAHwAAwBBAKUAAAD9AAoAfQAAAEEA pAAAAP0ACgB9AAEAQQBjAQAA/QAKAH0AAwBBAKYAAAD9AAoAfgAAAEEApQAAAP0ACgB+AAEA QQBjAQAA/QAKAH4AAwBBAKcAAAD9AAoAfwAAAEEApgAAAP0ACgB/AAEAQQBjAQAA/QAKAH8A AwBBAKgAAAD9AAoAgAAAAEEApwAAAP0ACgCAAAEAQQBjAQAA/QAKAIAAAwBBAKkAAAD9AAoA gQAAAEEAqAAAAP0ACgCBAAEAQQBjAQAA/QAKAIEAAwBBAFEAAAABAgYAgQAPAEsA1wBEABAI AABsAjgAOAA4ADgAOAAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoAKgAqACoA KgAqACoAKgAqACoACAIQAIIAAAAQAAQBAAAAAAABDwAIAhAAgwAAABAABAEAAAAAAAEPAAgC EACEAAAAEAAEAQAAAAAAAQ8ACAIQAIUAAAAQAAQBAAAAAAABDwAIAhAAhgAAABAABAEAAAAA AAEPAAgCEACHAAAAEAAEAQAAAAAAAQ8ACAIQAIgAAAAQAAQBAAAAAAABDwAIAhAAiQAAABAA BAEAAAAAAAEPAAgCEACKAAAAEAAEAQAAAAAAAQ8ACAIQAIsAAAAQAAQBAAAAAAABDwAIAhAA jQAAABAABAEAAAAAAAEPAAgCEACOAAAAEAAEAQAAAAAAAQ8ACAIQAI8AAAAQAAQBAAAAAAAB DwAIAhAAkAAAAAIABAEAAAAAAAEPAAgCEACRAAAAAgAEAQAAAAAAAQ8ACAIQAJIAAAACAAQB AAAAAAABDwAIAhAAlAAAAAIABAEAAAAAAAEPAAgCEACVAAAAAgAEAQAAAAAAAQ8ACAIQAJYA AAACAAQBAAAAAAABDwAIAhAAlwAAAAIABAEAAAAAAAEPAAgCEACYAAAAAgAEAQAAAAAAAQ8A CAIQAJsAAAACAAQBAAAAAAABDwAIAhAAnAAAAAIABAEAAAAAAAEPAAgCEACdAAAAAgAEAQAA AAAAAQ8ACAIQAJ4AAAACAAQBAAAAAAABDwAIAhAAnwAAAAIABAEAAAAAAAEPAAgCEACgAAAA AgAEAQAAAAAAAQ8A/QAKAIIAAABBAKkAAAD9AAoAggABAEEAYwEAAP0ACgCCAAMAQQBSAAAA /QAKAIMAAABBAFEAAAD9AAoAgwABAEEAYwEAAP0ACgCDAAMAQQBTAAAA/QAKAIQAAABBAFIA AAD9AAoAhAABAEEAYwEAAP0ACgCEAAMAQQBUAAAA/QAKAIUAAABBAFMAAAD9AAoAhQABAEEA YwEAAP0ACgCFAAMAQQBVAAAA/QAKAIYAAABBAFQAAAD9AAoAhgABAEEAYwEAAP0ACgCGAAMA QQBWAAAA/QAKAIcAAABBAFUAAAD9AAoAhwABAEEAYwEAAP0ACgCHAAMAQQBXAAAA/QAKAIgA AABBAFYAAAD9AAoAiAABAEEAYwEAAP0ACgCIAAMAQQBYAAAA/QAKAIkAAABBAFcAAAD9AAoA iQABAEEAYwEAAP0ACgCJAAMAQQBZAAAA/QAKAIoAAABBAFgAAAD9AAoAigABAEEAYwEAAP0A CgCKAAMAQQBaAAAA/QAKAIsAAABBAFkAAAD9AAoAiwABAEEAYwEAAP0ACgCNAAAAQQD+AAAA /QAKAI0AAQBBAGQBAAD9AAoAjgAAAEEA/wAAAP0ACgCOAAEAQQBkAQAA/QAKAI8AAABBABEB AAD9AAoAjwABAEEAZAEAAP0ACgCQAAAAQQAAAQAA/QAKAJAAAQBBAGQBAAD9AAoAkQAAAEUA ZQEAAP0ACgCRAAEAQQCKAQAA/QAKAJIAAABFAFEBAAD9AAoAkgABAEEAigEAAP0ACgCUAAAA QQAcAQAA/QAKAJQAAQBBABcBAAD9AAoAlQAAAEEAHgEAAP0ACgCVAAEAQQAXAQAA/QAKAJYA AABBABsBAAD9AAoAlgABAEEAFwEAAP0ACgCXAAAAQQAiAQAA/QAKAJcAAQBBABcBAAD9AAoA mAAAAEEAMwEAAP0ACgCYAAEAQQAXAQAA/QAKAJsAAABBAAgAAAD9AAoAmwABAEEAZgEAAP0A CgCcAAAAQQAJAAAA/QAKAJwAAQBBAGcBAAD9AAoAnQAAAEEACgAAAP0ACgCdAAEAQQBmAQAA /QAKAJ4AAABBAAsAAAD9AAoAngABAEEAZgEAAP0ACgCfAAAAQQA2AQAA/QAKAJ8AAQBBAGgB AAD9AAoAoAAAAEEANwEAAP0ACgCgAAEAQQBoAQAA1wA6AI4FAAAIAioAKgAqACoAKgAqACoA KgAqABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAIAhAAogAAAAIABAEAAAAA AAEPAAgCEACjAAAAAgAEAQAAAAAAAQ8ACAIQAKQAAAACAAQBAAAAAAABDwAIAhAApQAAAAIA BAEAAAAAAAEPAAgCEACmAAAAAgAEAQAAAAAAAQ8ACAIQAKcAAAACAAQBAAAAAAABDwAIAhAA qAAAAAIABAEAAAAAAAEPAAgCEACpAAAAAgAEAQAAAAAAAQ8ACAIQAKoAAAACAAQBAAAAAAAB DwAIAhAAqwAAAAIABAEAAAAAAAEPAAgCEACsAAAAAgAEAQAAAAAAAQ8ACAIQAK0AAAACAAQB AAAAAAABDwAIAhAArgAAAAIABAEAAAAAAAEPAAgCEACwAAAAAgAEAQAAAAAAAQ8ACAIQALIA AAACAAQBAAAAAAABDwAIAhAAswAAAAIABAEAAAAAAAEPAAgCEAC1AAAAAgAEAQAAAAAAAQ8A /QAKAKIAAABBADkAAAD9AAoAogABAEEAagEAAP0ACgCjAAAAQQDxAAAA/QAKAKMAAQBBAGkB AAD9AAoApAAAAEEA8gAAAP0ACgCkAAEAQQBpAQAA/QAKAKUAAABBAPMAAAD9AAoApQABAEEA aQEAAP0ACgCmAAAAQQD0AAAA/QAKAKYAAQBBAGkBAAD9AAoApwAAAEEA8AAAAP0ACgCnAAEA QQBpAQAA/QAKAKgAAABBADoAAAD9AAoAqAABAEEAaQEAAP0ACgCpAAAAQQD1AAAA/QAKAKkA AQBBAGkBAAD9AAoAqgAAAEEA9gAAAP0ACgCqAAEAQQBpAQAA/QAKAKsAAABBAPcAAAD9AAoA qwABAEEAaQEAAP0ACgCsAAAAQQD4AAAA/QAKAKwAAQBBAGkBAAD9AAoArQAAAEEA+QAAAP0A CgCtAAEAQQBpAQAA/QAKAK4AAABBADsAAAD9AAoArgABAEEAaQEAAP0ACgCwAAAAQQA/AQAA /QAKALAAAQBBAGsBAAD9AAoAsgAAAEMAQwEAAP0ACgCyAAEAQQBtAQAA/QAKALMAAABGAEIB AAD9AAoAswABAEEAbAEAAP0ACgC1AAAAQQCNAQAA/QAKALUAAQBBAJIBAADXACYAMAMAAEAB HAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAA+AhIAtgYAAAAAQAAAAAAAfQB9AAAA yAgRAMgIAAAAAEAAAAAAAAgAAAAAoAAEAAUABAAdAA8AAwMAAAAAAAEAAwADAAAA5QAKAAEA AgACAAIAEwDvAAYABgA3AAAAsAEWAAEAAwBbAFsABQAFAAEAWwBbAAUABQCxAY0AAQQHAAAA //87pAKAAABbAFsABQAFAFMAUwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQAD AwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAAKAAAAAAAAAJ////8BAAAAAQAAAAEA AAABAAAAAAAAAAAAAAABAAAAQBo8AACm/6b/sAEWAAEABQBeAF4ABQAFAAEAXgBeAAUABQCx AY0AAQQHAAAA//86pAKAAABeAF4ABQAFAFMAUwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEA AABkAAAAAQADAwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAD/fwAAAAAAAJ////8B AAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAwCA8AACg/6D/sAEWAAEABwBcAFwABQAFAAEA XABcAAUABQCxAY0AAQQHAAAA//87pAKAAABcAFwABQAFAFMAUwBTAFMAUwBTAFMAUwBTAFMA AgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAAKAAAA AAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAQBo8AACp/6n/sAEWAAEACQBb AFsABwAHAAEAWwBbAAcABwCxAY0AAQQHAAAA//86pAKAAABbAFsABwAHAFMAUwBTAFMAUwBT AFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8AAQABAAAAAP////8AAAAA//// //8AAAD/fwAAAAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAwCA8AACm/6b/ sAEWAAEACwBdAF0ABwAHAAEAXQBdAAcABwCxAY0AAQQHAAAA//87pAKAAABdAF0ABwAHAFMA UwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8AAQABAAAAAP// //8AAAAA//////8AAAAKAAAAAAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAA QBo8AACn/6f/sAEWAAEADQBaAFoACwALAAEAWgBaAAsACwCxAY0AAQQHAAAA//87pAKAAABa AFoACwALAFMAUwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8A AQABAAAAAP////8AAAAA//////8AAAAKAAAAAAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAA AAAAAAABAAAAwBlaAAAHAAIAsAEWAAEADwBbAFsACwALAAEAWwBbAAsACwCxAY0AAQQHAAAA //87pAKAAABbAFsACwALAFMAUwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQAD AwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAAKAAAAAAAAAJ////8BAAAAAQAAAAEA AAABAAAAAAAAAAAAAAABAAAAQBo8AACm/6b/sAEWAAEAEQBeAF4ACwALAAEAXgBeAAsACwCx AY0AAQQHAAAA//86pAKAAABeAF4ACwALAFMAUwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEA AABkAAAAAQADAwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAD/fwAAAAAAAJ////8B AAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAwCA8AACg/6D/sAEWAAEAEwBcAFwACwALAAEA XABcAAsACwCxAY0AAQQHAAAA//87pAKAAABcAFwACwALAFMAUwBTAFMAUwBTAFMAUwBTAFMA AgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAAKAAAA AAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAQBo8AACp/6n/sAEWAAEAFQBW AFcAEAAQAAEA VgBXABAAEACxAY0AAQQHAAAA//87pAKAAABWAFcAEAAQAFMAUwBTAFMAUwBT AFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8AAQABAAAAAP////8AAAAA//// //8AAAAKAAAAAAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAQBo8AAD9//3/ sAEWAAEAFwBYAFgAEAAQAAEAWABYABAAEACxAY0AAQQHAAAA//87pAKAAABYAFgAEAAQAFMA UwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8AAQABAAAAAP// //8AAAAA//////8AAAAKAAAAAAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAA QBo8AAD8//z/sAEWAAEAGQCOAI4AAAAAAAEAjgCOAAAAAACxAY0AAQQHAAAA//87pAKAAACO AI4AAAAAAFMAUwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8A AQABAAAAAP////8AAAAA//////8AAAAKAAAAAAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAA AAAAAAABAAAAQBo8AACm/6b/sAEWAAEAGwCQAJAAAAAAAAEAkACQAAAAAACxAY0AAQQHAAAA //86pAKAAACQAJAAAAAAAFMAUwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEAAABkAAAAAQAD AwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAD/fwAAAAAAAJ////8BAAAAAQAAAAEA AAABAAAAAAAAAAAAAAABAAAAwCA8AACg/6D/sAEWAAEAHQCVAJUAAAAAAAEAlQCVAAAAAACx AY0AAQQHAAAA//86pAKAAACVAJUAAAAAAFMAUwBTAFMAUwBTAFMAUwBTAFMAAgAUAEEAAAEA AABkAAAAAQADAwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAD/fwAAAAAAAJ////8B AAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAwCA8AACm/6b/sAEWAAEAHwCXAJcAAAAAAAEA lwCXAAAAAACxAY0AAQQHAAAA//87pAKAAACXAJcAAAAAAFMAUwBTAFMAUwBTAFMAUwBTAFMA AgAUAEEAAAEAAABkAAAAAQADAwMAAAABf/8AAQABAAAAAP////8AAAAA//////8AAAAKAAAA AAAAAJ////8BAAAAAQAAAAEAAAABAAAAAAAAAAAAAAABAAAAQBo8AACn/6f/ewgrAHsIAQBb AFsABQAFAAAAAAABAAAABABDAAMAEAAAAAAAAAAAAAAAAAAAAAB7CCsAewgBAF4AXgAFAAUA AAAAAAIAAAAEAEUAAwAQAAAAAAAAAAAAAAAAAAAAAHsIKwB7CAEAXABcAAUABQAAAAAAAwAA AAQARwADABAAAAAAAAAAAAAAAAAAAAAAewgrAHsIAQBbAFsABwAHAAAAAAAEAAAABABpAAMA EAAAAAAAAAAAAAAAAAAAAAB7CCsAewgBAF0AXQAHAAcAAAAAAAUAAAAEAG4AAwAQAAAAAAAA AAAAAAAAAAAAAHsIKwB7CAEAWgBaAAsACwAAAAAABgAAAAQAIQADABAAAAAAAAAAAAAAAAAA AAAAewgrAHsIAQBbAFsACwALAAAAAAAHAAAABAAjAAMAEAAAAAAAAAAAAAAAAAAAAAB7CCsA ewgBAF4AXgALAAsAAAAAAAgAAAAEACQAAwAQAAAAAAAAAAAAAAAAAAAAAHsIKwB7CAEAXABc AAsACwAAAAAACQAAAAQAJQADABAAAAAAAAAAAAAAAAAAAAAAewgrAHsIAQBWAFcAEAAQAAAA AAAKAAAABAAXAAMAEAAAAAAAAAAAAAAAAAAAAAB7CCsAewgBAFgAWAAQABAAAAAAAAsAAAAE ABgAAwAQAAAAAAAAAAAAAAAAAAAAAHsIKwB7CAEAjgCOAAAAAAAAAAAADAAAAAQAAwADABAA AAAAAAAAAAAAAAAAAAAAewgrAHsIAQCQAJAAAAAAAAAAAAANAAAABAAEAAMAEAAAAAAAAAAA AAAAAAAAAAB7CCsAewgBAJUAlQAAAAAAAAAAAA4AAAAEAAEAAwAQAAAAAAAAAAAAAAAAAAAA AHsIKwB7CAEAlwCXAAAAAAAAAAAADwAAAAQAAgADABAAAAAAAAAAAAAAAAAAAAAAZwgXAGcI AAAAAAAAAAAAAAIAAf////8DRAAACgAAAAkIEAAABhAAzVbMBxAAAwAGBgAACwIUAAAAAAAB AAAAFwAAAEvnAADi7gAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAIAPyp8dJNYlA/XwAC AAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAABAGBAAIAwQQUAAAAFQAA AIMAAgAAAIQAAgAAAKEAIgABAAQBAQABAAEABAACAAH/AAAAAAAA4D8AAAAAAADgPwAAVQAC AAoAfQAMAAAAAAAAEg8ABgAEAH0ADAABAAEAJBwPAAYABAAAAg4AAQAAABcAAAAAABMAAAAI AhAAAQAAABMABAEAAAAAAAEPAAgCEAACAAAAEwBoAQAAAAAAAQ8ACAIQAAMAAAATAGgBAAAA AAABDwAIAhAABAAAABMAaAEAAAAAAAEPAAgCEAAFAAAAEwBoAQAAAAAAAQ8ACAIQAAYAAAAT AGgBAAAAAAABDwAIAhAABwAAABMAaAEAAAAAAAEPAAgCEAAIAAAAEwBoAQAAAAAAAQ8ACAIQ AAkAAAATAGgBAAAAAAABDwAIAhAACgAAABMAaAEAAAAAAAEPAAgCEAALAAAAEwBoAQAAAAAA AQ8ACAIQAAwAAAATAGgBAAAAAAABDwAIAhAADQAAABMAaAEAAAAAAAEPAAgCEAAOAAAAEwBo AQAAAAAAAQ8ACAIQAA8AAAATAGgBAAAAAAABDwAIAhAAEAAAABMAaAEAAAAAAAEPAAgCEAAR AAAAEwBoAQAAAAAAAQ8ACAIQABIAAAATAGgBAAAAAAABDwAIAhAAEwAAABMAaAEAAAAAAAEP AAgCEAAUAAAAEwBoAQAAAAAAAQ8ACAIQABUAAAATAGgBAAAAAAABDwAIAhAAFgAAABMAaAEA AAAAAAEPAP0ACgABAAAATQCGAQAA/QAKAAEAAQBNAIUBAAD9AAoAAgAAAEcABQAAAH4CCgAC AAEATwAAi75AvgAoAAIAAgBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9 AAoAAwAAAEcAAwAAAH4CCgADAAEATwDIcAhBvgAoAAMAAgBAAEAAQABAAEAAQABAAEAAQABA AEAAQABAAEAAQABAAEAAEgD9AAoABAAAAEcABwAAAH4CCgAEAAEATwCyi4kAvgAoAAQAAgBA AEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9AAoABQAAAEcA/QAAAH4CCgAF AAEAUACg4OlAvgAoAAUAAgBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9 AAoABgAAAEcAMgEAAH4CCgAGAAEAUABOTpwYvgAoAAYAAgBAAEAAQABAAEAAQABAAEAAQABA AEAAQABAAEAAQABAAEAAEgD9AAoABwAAAEcAhwEAAH4CCgAHAAEAUAAAmsxAvgAoAAcAAgBA AEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9AAoACAAAAEcABgAAAH4CCgAI AAEAUQDytP0BvgAoAAgAAgBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9 AAoACQAAAEcANAEAAH4CCgAJAAEAUQAgUuRAvgAoAAkAAgBAAEAAQABAAEAAQABAAEAAQABA AEAAQABAAEAAQABAAEAAEgD9AAoACgAAAEcANQEAAH4CCgAKAAEAUAAEry9BvgAoAAoAAgBA AEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9AAoACwAAAEcAOQEAAH4CCgAL AAEAUAAAoHtAvgAoAAsAAgBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9 AAoADAAAAEcAPAEAAH4CCgAMAAEAUAA4iwxBvgAoAAwAAgBAAEAAQABAAEAAQABAAEAAQABA AEAAQABAAEAAQABAAEAAEgD9AAoADQAAAEcAOwEAAH4CCgANAAEAUABmKI0DvgAoAA0AAgBA AEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9AAoADgAAAEcABAAAAH4CCgAO AAEAUQDqB1kCvgAoAA4AAgBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9 AAoADwAAAEcAPQEAAL4AKgAPAAEAUQBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABA AEAAEgD9AAoAEAAAAEcAPgEAAH4CCgAQAAEAUADYugBBvgAoABAAAgBAAEAAQABAAEAAQABA AEAAQABAAEAAQABAAEAAQABAAEAAEgD9AAoAEQAAAEcAQQEAAH4CCgARAAEAUAB4mhBBvgAo ABEAAgBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgD9AAoAEgAAAEcARQEA AH4CCgASAAEAUAAAe9lAvgAoABIAAgBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABA AEAAEgD9AAoAEwAAAEcASAEAAH4CCgATAAEAUAAAbv9AvgAoABMAAgBAAEAAQABAAEAAQABA AEAAQABAAEAAQABAAEAAQABAAEAAEgD9AAoAFAAAAEcAbgEAAH4CCgAUAAEAUQAAAAAAvgAo ABQAAgBAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAEgABAgYAFQAAAEwA/QAK ABYAAABSAIQBAAAGACMAFgABAE4AAAAASJnGoEEAAHDo1vwNACUCABQAAcABwBkQ5aTXADAA XwcAAKQBHABIAEgASABIAEgASABIAEgASABIAEgASABIADwASABIAEgASABIAAoAPgISALYA AAAAAEAAAAAAAJYAlgAAAMgIEQDICAAAAABAAAAAAAAIAAAAAKAABAADAAIAHQAPAAMCAAEA AAABAAIAAgABAWcIFwBnCAAAAAAAAAAAAAACAAH/////A0QAAAoAAAAJCBAAAAYQAM1WzAcQ AAMABgYAAAsCEAAAAAAAAAAAAAAAAAAz8AAADQACAAEADAACAGQADwACAAEAEQACAAAAEAAI APyp8dJNYlA/XwACAAEAKgACAAAAKwACAAAAggACAAEAgAAIAAAAAAAAAAAAJQIEAAAABAGB AAIAwQQUAAAAFQAAAIMAAgAAAIQAAgAAAKEAIgABAAQBAQABAAEABAACAAH/AAAAAAAA4D8A AAAAAADgP8ABVQACAAoAAAIOAAAAAAAAAAAAAAAAAAAAPgISALYAAAAAAEAAAAAAAAAAAAAA AMgIEQDICAAAAABAAAAAAAAIAAAAAB0ADwADAAAAAAAAAQAAAAAAAABnCBcAZwgAAAAAAAAA AAAAAgAB/////wNEAAAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAD+//// BQAAAAYAAAAHAAAACAAAAP7///8KAAAA/v////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////7/AAADCgEAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAALQAAAAHAAAAAQAAAEAAAAAEAAAASAAAAAgAAABcAAAAEgAAAHAAAAAMAAAAlAAAAA0A AACgAAAAEwAAAKwAAAACAAAAECcAAB4AAAAMAAAAU3RldmUgU2hlbmcAHgAAAAwAAABTdGV2 ZSBTaGVuZwAeAAAAHAAAAE1pY3Jvc29mdCBNYWNpbnRvc2ggRXhjZWwAAABAAAAA4JHk7APs ygFAAAAAsHlqZ8lIzQEDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAA AwoBAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADgAAAACQAAAAEA AABQAAAADwAAAFgAAAAXAAAAZAAAAAsAAABsAAAAEAAAAHQAAAATAAAAfAAAABYAAACEAAAA DQAAAIwAAAAMAAAAvAAAAAIAAAAQJwAAHgAAAAQAAABDTVUAAwAAAAAADgALAAAAAAAAAAsA AAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAADAAAACwAAAERhdGEgTW9kZWwACgAAAFRMRCBT dGF0cwAHAAAAU2hlZXQ0AAwQAAACAAAAHgAAAAsAAABXb3Jrc2hlZXRzAAMAAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8CAAEA /////yAIAgAAAAAAwAAAAAAAAEYkAAAATWljcm9zb2Z0IEV4Y2VsIDk3IC0gMjAwNCBXb3Jr c2hlZXQA/v///zhGSUIOAAAARXhjZWwuU2hlZXQuOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAkAAABiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --B_3422345940_4754044-- --B_3422345940_4757614 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFDssjBl5YXvaD1ab24d6lQggQ6wzMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYxMjE4MzkwMFowDQYJ KoZIhvcNAQEBBQAEggEAqv3hpDXwyLKOaDZsP9qJ5Pa7gTUzR4TsiPxQsyP0+Dgr9Hqc8lzr BIzyH7GvUXo5yrpDIW43DdKhGuqX2BQTDkIPFDBERZ240jCPQzhEpiwMCQ8vNPh+JKFbUJlU aJOEKALfGUrUI9SjAtr9oTrbE5LgDlhf5gA343/Cj0NgP23Xfre4LI/7K+ZIc5prjKK5kE2D /Y0regkjPUbFiAuC3+wJD6suU99OZYF5dB9GF40F3KLx/8ztaT/ftXNkrxt1YUQsQLpRgs9O 55c+cwsciyO7AUkE96cTVntLVGEOFeayuKlHsddQf8Tyd78pypUsGPOyXjGTeu7cwa2I2dLs DQ== --B_3422345940_4757614-- From michele@blacknight.ie Tue Jun 12 11:51:10 2012 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 79B9121F85F6 for ; Tue, 12 Jun 2012 11:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FROM_NONAME=1.294] 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 posPhTOwiYAE for ; Tue, 12 Jun 2012 11:51:09 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id B5AB621F85DF for ; Tue, 12 Jun 2012 11:51:08 -0700 (PDT) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0309.002; Tue, 12 Jun 2012 19:51:07 +0100 From: "\"Michele Neylon :: Blacknight\"" To: Steve Sheng Thread-Topic: [weirds] Divide and Conquer Thread-Index: AQHNQwdSPeBGUHdfd0ObjzpB/oujwpb2/nEAgAADYgA= Date: Tue, 12 Jun 2012 18:51:06 +0000 Message-ID: <4F2538C315ACAC42AD334C533C247C47565718EA@bkexchmbx01.blacknight.local> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.101.219.118] Content-Type: text/plain; charset="us-ascii" Content-ID: <70F7914E485A784DB03B3BC3DABBA9DB@blacknight.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Web Extensible Internet Registration Data Service Working Group Subject: Re: [weirds] Divide and Conquer 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, 12 Jun 2012 18:51:10 -0000 Steve It's interesting to see that there is variety even when more than one exten= sion is on the same backend. Regards Michele On 12 Jun 2012, at 19:39, Steve Sheng wrote: > -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From bob@coldrain.net Tue Jun 12 11:51:59 2012 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 5C4EF21F85F6 for ; Tue, 12 Jun 2012 11:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mioQxsEvqcG for ; Tue, 12 Jun 2012 11:51:58 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3C621F85DF for ; Tue, 12 Jun 2012 11:51:58 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5CIprYQ031869 for ; Tue, 12 Jun 2012 14:51:53 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5CIprQd031866 for ; Tue, 12 Jun 2012 14:51:53 -0400 Date: Tue, 12 Jun 2012 14:51:53 -0400 (EDT) From: Bob Bruen To: weirds@ietf.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [weirds] policy & tech 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, 12 Jun 2012 18:51:59 -0000 Hi Andrew, On Tue, 12 Jun 2012 14:14:00 -0400, Andrew Sullivan wrote: > No, I want the protocol to make _possible_ a policy. That is a policy decision. By adding capabilities to anything you create its potential use. By deciding not to add, you are denying its use. Either way, it's a policy decision at an early stage and it should be considered carefully. This particular capability is chosen and another is not. Why pick one and not another? > It could be that nobody will turn this knob on. If that were to happen, > then the protocol would have a needless feature, and that is bad. > But I predict that someone will turn that knob on, ... There is no doubt that it will be used, just like thick and thin whois records limit what is seen on a whois record. There are also other ways used to limit the data seen. > ...because a significant chunk of WHOIS complaints come from people who > claim that the exposure of all that contact information is in violation > of certain national implementations of EU data protection directorates. That, in fact, is an established claim. > I have no idea whether that is true, and don't care, because if we have > a protocol that supports such policy decisions then we have offered the > necessary technical supports. Well, you should care because you are helping to create the technology which will determine the use of whois for a long time. > What you appear to be arguing is that you have a preferred policy > outcome, and that therefore the protocol should be written to make > sure an alternative isn't possible. I do have a preferred outcome, as do you, and we both have expressed our opinion. I am not arguing for my choice, but, again, arguing for consideration of what appears to have been chosen, because of downstream consequences. > If that's what we want, then there is absolutely no reason whatsoever to > continue with this work. Let's leave WHOIS in place. There is no reason > for us to invent a new way to express exactly the same limitations. Are you saying that only reason to move to rest is to be able to limit what people can see in whois data? If that is true, then you are right, there is no point to continue with the work. I was under the delusion that there other reasons to improve whois. --bob -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From michele@blacknight.ie Tue Jun 12 11:56:33 2012 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 2CCEC21F8637 for ; Tue, 12 Jun 2012 11:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FROM_NONAME=1.294] 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 5VaW5Fr3ONVO for ; Tue, 12 Jun 2012 11:56:32 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 3F44921F85A1 for ; Tue, 12 Jun 2012 11:56:31 -0700 (PDT) Received: from BKEXCHMBX01.blacknight.local ([fe80::76:af74:8c72:96ac]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0309.002; Tue, 12 Jun 2012 19:56:30 +0100 From: "\"Michele Neylon :: Blacknight\"" To: Bob Bruen Thread-Topic: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt Thread-Index: AQHNSM0TLPU/DY28QEaCcVSzVGzZsw== Date: Tue, 12 Jun 2012 18:56:30 +0000 Message-ID: <4F2538C315ACAC42AD334C533C247C475657194B@bkexchmbx01.blacknight.local> References: In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.101.219.118] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:56:33 -0000 Bob Not all registries' whois policies work the same way. If "weirds" is to replace current usage scenarios then having that kind of = flexibility is essential. Regards Michele On 12 Jun 2012, at 18:16, Bob Bruen wrote: > Hi Andrew, >=20 > IMHO, there should not be a different service depending on credentials. >=20 > The original whois presented all the available data, then the amount was = cut back. It should be like the original, so that all the data is available= to anyone. >=20 > --bob >=20 >=20 > On Tue, 12 Jun 2012, Andrew Sullivan wrote: >=20 >> On Tue, Jun 12, 2012 at 10:04:55PM +0800, Ning Kong wrote: >>=20 >> ... >> One of the goals so far has been to permit differential levels of >> service depending on credentials. (I believe quite strongly that if >> we do not provide that functionality, we will have completely botched >> this work.) >> ... >=20 >=20 > --=20 > Dr. Robert Bruen > http://knujon.org > http://coldrain.net/bruen > +1.802.579.6288 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From ajs@anvilwalrusden.com Tue Jun 12 12:22:38 2012 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 CB7EE21F8625 for ; Tue, 12 Jun 2012 12:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW1PhIetCYyY for ; Tue, 12 Jun 2012 12:22:38 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07021F85C7 for ; Tue, 12 Jun 2012 12:22:38 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6A5CC1ECB41C for ; Tue, 12 Jun 2012 19:22:37 +0000 (UTC) Date: Tue, 12 Jun 2012 15:22:35 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612192235.GJ25201@mail.yitter.info> References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> <00ef01cd48a4$58b44ce0$0a1ce6a0$@cnnic.cn> <20120612144223.GF16548@mail.yitter.info> <4FD75A15.60404@arin.net> <20120612155643.GI16548@mail.yitter.info> <4FD7796D.60608@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD7796D.60608@arin.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 19:22:38 -0000 On Tue, Jun 12, 2012 at 01:16:29PM -0400, Andy Newton wrote: > >http header to warn that some data has been redacted because of lack > >of authentication? > > That works for me. Suggestions? Well, that's the problem. The natural place to put this, AFAICT, is in the Warning: header field in an http response. I suspect the right thing to to would be to specify that a client MAY use such-and-thus Warning: header as an indication that it could get more information if it had the right credentials. Unfortunately, I can see nothing in RFC 2616 that is a natual candidate. The httpbis WG is working on a replacement, however, and in part 7 (!) of that replacement there is a Warn Code Registry defined. Maybe that's what we ought to do. It will have no effect on simple web-browser type clients, but a more sophisticated client could use the warn code. I can ask about this on httpbis@ if it seems worth chasing. > >That's not true. First, Murray and John have both said that they'd be > >entirely willing to trade away the accessibility of contact > >information for authenticated confirmation that two resources > >(e.g. two names or two netblocks) are related according to some > >criteria. I've heard law enforcement people say the same thing, so > >I'm sure it's valuable. > I would like to see a concrete example of the first use case as > "related" is a fairly subjective term. "Please tell me if $object1 and $object2 are registered by the same registrant," for instance. (Unpacking "same registrant" is going to be local policy-dependent. Maybe it will mean "same street address" or "same email domain" or merely "same registrant id".) The argument that anti-abuse and law enforcement people make about needing "complete and accurate" WHOIS information in very many cases boils down to, "I need to know whether these networks|netnames are under the control of the same person." Anti-abuse people don't really _care_ who it is exactly, and LE people could get a warrant if they needed to know who it was exactly. > The second use case I understand and is easy to do with simple redaction. Yes, but if I'm the client I want to know that the data is there, but that I can't have it. Security people would call that an information leak, but in this case it's a feature, because we want a signal to this effect. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Jun 12 12:35:08 2012 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 9944421F86E2 for ; Tue, 12 Jun 2012 12:35:08 -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 oBKRQIoLHkJL for ; Tue, 12 Jun 2012 12:35:08 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id F340121F867C for ; Tue, 12 Jun 2012 12:35:07 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3F20A1ECB41C for ; Tue, 12 Jun 2012 19:35:07 +0000 (UTC) Date: Tue, 12 Jun 2012 15:35:05 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612193505.GL25201@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] policy & tech 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, 12 Jun 2012 19:35:08 -0000 On Tue, Jun 12, 2012 at 02:51:53PM -0400, Bob Bruen wrote: > > That is a policy decision. By adding capabilities to anything you > create its potential use. You are equivocating on the word "policy" here. Of course it is true that technology shapes the world. But the Working Group has already been chartered, and it was chartered on the basis of a number of claims about the things we were aiming to do. The goal as I understood it was to support various potential uses -- "policies" -- in a new protocol. The claims included the following (from the charter): The WHOIS protocol does not offer any differential service; it cannot differentiate among clients to offer different subsets of information or to allow different access rates to it. […] and may use standard features of HTTP to support differential service levels to different classes of user. I will object, very strongly, if this WG produces things that do not possibly provide such differentiation. I leave to the chairs the determination of whether further discussion of this question is on-topic for the list, but I don't have more to say on the topic. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From dblumenthal@pir.org Tue Jun 12 12:50:28 2012 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 A385A21F86F0 for ; Tue, 12 Jun 2012 12:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 uEplHH-oM9Tq for ; Tue, 12 Jun 2012 12:50:28 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com (mail.pir.org [72.44.190.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6901E21F86D8 for ; Tue, 12 Jun 2012 12:50:26 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Tue, 12 Jun 2012 15:50:25 -0400 From: Don Blumenthal To: Bob Bruen , "weirds@ietf.org" Date: Tue, 12 Jun 2012 15:50:23 -0400 Thread-Topic: [weirds] policy & tech Thread-Index: Ac1I1JvoGs/rF9cMS/2JlqmEueosGA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] policy & tech 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, 12 Jun 2012 19:50:28 -0000 Ok. Time for somebody else to step in here. First, for reasons that have been explored already, the suggestion that WEIRDS wouldn't be making a policy decision by excluding differential services capabilities is nonsense. In fact, the statement that the capabilities will be used if feasible under a new protocol supports that statement. You're asking WEIRDS to prevent the community from implementing a capability that it wants based on your view of the concept, not on whether a protocol can offer the ability. To address another topic, EU privacy issues already exist under the current protocol and are handled on an as applicable basis. Restful or another other new approach will continue to afford that ability, and it's not within the WEIRDS purview to structure our work based on laws that may or may not apply in any given situation. Don On 6/12/12 2:51 PM, "Bob Bruen" wrote: > >Hi Andrew, > >On Tue, 12 Jun 2012 14:14:00 -0400, Andrew Sullivan wrote: > >> No, I want the protocol to make _possible_ a policy. > >That is a policy decision. By adding capabilities to anything you create >its potential use. By deciding not to add, you are denying its use. >Either=20 >way, it's a policy decision at an early stage and it should be considered >carefully. This particular capability is chosen and another is not. Why >pick one and not another? > >> It could be that nobody will turn this knob on. If that were to >>happen,=20 >> then the protocol would have a needless feature, and that is bad. >> But I predict that someone will turn that knob on, ... > >There is no doubt that it will be used, just like thick and thin whois >records limit what is seen on a whois record. There are also other ways >used to limit the data seen. > >> ...because a significant chunk of WHOIS complaints come from people who >> claim that the exposure of all that contact information is in violation >> of certain national implementations of EU data protection directorates. > >That, in fact, is an established claim. > >> I have no idea whether that is true, and don't care, because if we have >> a protocol that supports such policy decisions then we have offered the >> necessary technical supports. > >Well, you should care because you are helping to create the technology >which will determine the use of whois for a long time. > >> What you appear to be arguing is that you have a preferred policy >> outcome, and that therefore the protocol should be written to make >> sure an alternative isn't possible. > >I do have a preferred outcome, as do you, and we both have expressed >our opinion. I am not arguing for my choice, but, again, arguing for >consideration of what appears to have been chosen, because of downstream >consequences. > >> If that's what we want, then there is absolutely no reason whatsoever >>to=20 >> continue with this work. Let's leave WHOIS in place. There is no >>reason=20 >> for us to invent a new way to express exactly the same limitations. > >Are you saying that only reason to move to rest is to be able to limit >what people can see in whois data? If that is true, then you are right, >there is no point to continue with the work. I was under the delusion >that there other reasons to improve whois. > > --bob >--=20 >Dr. Robert Bruen >http://knujon.org >http://coldrain.net/bruen >+1.802.579.6288 > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From bob@coldrain.net Tue Jun 12 13:17:18 2012 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 5D52C21F85F6 for ; Tue, 12 Jun 2012 13:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZsTH0pB-atw for ; Tue, 12 Jun 2012 13:17:17 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF1921F85C7 for ; Tue, 12 Jun 2012 13:17:14 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5CKHA36000938 for ; Tue, 12 Jun 2012 16:17:10 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5CKHASn000934 for ; Tue, 12 Jun 2012 16:17:10 -0400 Date: Tue, 12 Jun 2012 16:17:10 -0400 (EDT) From: Bob Bruen To: weirds@ietf.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [weirds] policy & tech (last one) 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, 12 Jun 2012 20:17:18 -0000 Hi Don, I agree with Andrew that this should stop now and this will be my last post on this topic, but I can't ignore what you've said. On Tue, 12 Jun 2012 15:50:23 -0400 Don Blumenthal wrote: > First, for reasons that have been explored already, the suggestion that > WEIRDS wouldn't be making a policy decision by excluding differential > services capabilities is nonsense. I assume this is aimed at me and not Andrew, but if you go back and read the emails, I never said that. If you find such a statement, feel free to send it to me directly. > In fact, the statement that the capabilities will be used if feasible > under a new protocol supports that statement. You're asking WEIRDS to > prevent the community from implementing a capability that it wants based > on your view of the concept, not on whether a protocol can offer the > ability. Really? The "community" is generally a subset, not 100%. I like to think I am part of the community as much as anyone else, unless disagreeing excludes me from the community. There are lots of things people want, that they don't get and sometimes for good reason. If simply wanting something got it, life would be interesting. I was hoping for thoughtful. All I ever asked was for such things to be considered carefully. The fact I am getting beaten up for suggesting it proves my point. Once the ball starts rolling, it does not get stopped or its path altered. This project matters and will have consequences beyond just looking up a domain name information record. --bob -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From johnl@iecc.com Tue Jun 12 13:24:48 2012 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 2B6E021F8678 for ; Tue, 12 Jun 2012 13:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efKwuG7PcjDV for ; Tue, 12 Jun 2012 13:24:47 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9D121F84A1 for ; Tue, 12 Jun 2012 13:24:47 -0700 (PDT) Received: (qmail 49640 invoked from network); 12 Jun 2012 20:24:45 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Jun 2012 20:24:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fd7a58d.xn--btvx9d.k1206; i=johnl@user.iecc.com; bh=9ULeQCJ/VHwUEJZVNm7SEHYd4votm7NN486Otm9T1D0=; b=H3myL2vhA8DVqJTM7UAf7NU4F+0DJozpEyxRtEdx7kr2ExSZGkCX/2fNqgJkLzKOGO5T5FUD5O0TrAP16gecJr8iiEWXUhUCf978k2sGUW0pXnprdY8KyD7axCOCqXiCnGGvSHlGU87mo9zaPU70FWo4A/17GEMiAzJ1F+Y3O+o= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 12 Jun 2012 20:24:23 -0000 Message-ID: <20120612202423.75669.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <20120612155643.GI16548@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] decomposition and redaction, was FW: I-D Action 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, 12 Jun 2012 20:24:48 -0000 >> Our experience is that people want all the information in one go. > >I'm sure this is true. Of course, this is partly because everyone has >a large number of tools built around the assumptions of WHOIS. I >think our hope is to offer something better, right? Yes, but I think that people building servers would be unhappy to find that what they had thought was one query is now six queries, since that turns a query rate of N into a rate of 6N. I can think of a variety of straightforward ways to indicate partial redaction, other than a non-standard HTTP header, from a reserved field value that means redacted (a single space, perhaps) to adding IS-REDACTED flags to the components that might be affected. R's, John From bill.smith@paypal-inc.com Tue Jun 12 13:27:03 2012 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 2128121F867D for ; Tue, 12 Jun 2012 13:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvJbKVQyytj6 for ; Tue, 12 Jun 2012 13:27:02 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by ietfa.amsl.com (Postfix) with ESMTP id 2513B21F8679 for ; Tue, 12 Jun 2012 13:27:02 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-ems-proccessed: x-ems-stamp:Content-Type:Content-ID: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=JCTNshCpymlaf3SbHkQKuNQD2+KEE0Au92MRKhXVgsFeaXDTV6Ak7AGt +vKr3VD7YZht2fG+VVljsqVxMldULg9xglbSuzwL+W0eukl9J9yGVSX1U R4kawSraa9wa1Jw; 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=1339532822; x=1371068822; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aXbmX1sbZPyJWRsR+n30CnXfG5LHqG3ZxmP5HrahNuk=; b=mckp8gKNhfB8qIG5LeCQtO48tdGZlQSXjm0LMQZsr9Xh+L5J7EYDlMJN O6M3mT+PiZNohKNlw5azQ/yI17FLAlr08CfXb2dRVC0ReDHbnbTktoH+5 a5FS623kLBKjDHv; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.75,759,1330934400"; d="scan'208";a="8558220" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-003.corp.ebay.com) ([10.101.112.212]) by den-mipot-002.corp.ebay.com with ESMTP; 12 Jun 2012 13:27:02 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-003.corp.ebay.com ([fe80::55d3:9d86:3fc8:dbf4%14]) with mapi id 14.01.0339.001; Tue, 12 Jun 2012 14:26:59 -0600 From: "Smith, Bill" To: Don Blumenthal Thread-Topic: [weirds] policy & tech Thread-Index: AQHNSMxu5TCkBII70kGDaS13O5LipZb3fDGAgAAJ24A= Date: Tue, 12 Jun 2012 20:26:58 +0000 Message-ID: <5603201B-6C2E-47C0-9221-75819A9651F7@paypal.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: tlddRq4TdtScOTGZcEyKIQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <854209AD02C43F48BB79ECCEC322E3AD@corp.ebay.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: "weirds@ietf.org" Subject: Re: [weirds] policy & tech 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, 12 Jun 2012 20:27:03 -0000 *strongly agree* On Jun 12, 2012, at 3:50 PM, "Don Blumenthal" wrote: > Ok. Time for somebody else to step in here. >=20 > First, for reasons that have been explored already, the suggestion that > WEIRDS wouldn't be making a policy decision by excluding differential > services capabilities is nonsense. In fact, the statement that the > capabilities will be used if feasible under a new protocol supports that > statement. You're asking WEIRDS to prevent the community from implementin= g > a capability that it wants based on your view of the concept, not on > whether a protocol can offer the ability. >=20 > To address another topic, EU privacy issues already exist under the > current protocol and are handled on an as applicable basis. Restful or > another other new approach will continue to afford that ability, and it's > not within the WEIRDS purview to structure our work based on laws that ma= y > or may not apply in any given situation. >=20 > Don >=20 > On 6/12/12 2:51 PM, "Bob Bruen" wrote: >=20 >>=20 >> Hi Andrew, >>=20 >> On Tue, 12 Jun 2012 14:14:00 -0400, Andrew Sullivan wrote: >>=20 >>> No, I want the protocol to make _possible_ a policy. >>=20 >> That is a policy decision. By adding capabilities to anything you create >> its potential use. By deciding not to add, you are denying its use. >> Either=20 >> way, it's a policy decision at an early stage and it should be considere= d >> carefully. This particular capability is chosen and another is not. Why >> pick one and not another? >>=20 >>> It could be that nobody will turn this knob on. If that were to >>> happen,=20 >>> then the protocol would have a needless feature, and that is bad. >>> But I predict that someone will turn that knob on, ... >>=20 >> There is no doubt that it will be used, just like thick and thin whois >> records limit what is seen on a whois record. There are also other ways >> used to limit the data seen. >>=20 >>> ...because a significant chunk of WHOIS complaints come from people who >>> claim that the exposure of all that contact information is in violation >>> of certain national implementations of EU data protection directorates. >>=20 >> That, in fact, is an established claim. >>=20 >>> I have no idea whether that is true, and don't care, because if we have >>> a protocol that supports such policy decisions then we have offered the >>> necessary technical supports. >>=20 >> Well, you should care because you are helping to create the technology >> which will determine the use of whois for a long time. >>=20 >>> What you appear to be arguing is that you have a preferred policy >>> outcome, and that therefore the protocol should be written to make >>> sure an alternative isn't possible. >>=20 >> I do have a preferred outcome, as do you, and we both have expressed >> our opinion. I am not arguing for my choice, but, again, arguing for >> consideration of what appears to have been chosen, because of downstream >> consequences. >>=20 >>> If that's what we want, then there is absolutely no reason whatsoever >>> to=20 >>> continue with this work. Let's leave WHOIS in place. There is no >>> reason=20 >>> for us to invent a new way to express exactly the same limitations. >>=20 >> Are you saying that only reason to move to rest is to be able to limit >> what people can see in whois data? If that is true, then you are right, >> there is no point to continue with the work. I was under the delusion >> that there other reasons to improve whois. >>=20 >> --bob >> --=20 >> Dr. Robert Bruen >> http://knujon.org >> http://coldrain.net/bruen >> +1.802.579.6288 >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From ajs@anvilwalrusden.com Tue Jun 12 13:34:28 2012 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 407CB11E807F for ; Tue, 12 Jun 2012 13:34:28 -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 0qJYiVnpNe2M for ; Tue, 12 Jun 2012 13:34:27 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B71AD11E8072 for ; Tue, 12 Jun 2012 13:34:27 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 16EFE1ECB41C for ; Tue, 12 Jun 2012 20:34:27 +0000 (UTC) Date: Tue, 12 Jun 2012 16:34:25 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612203425.GO25201@mail.yitter.info> References: <20120612155643.GI16548@mail.yitter.info> <20120612202423.75669.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120612202423.75669.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] decomposition and redaction, was FW: I-D Action 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, 12 Jun 2012 20:34:28 -0000 On Tue, Jun 12, 2012 at 08:24:23PM -0000, John Levine wrote: > I can think of a variety of straightforward ways to indicate partial > redaction, other than a non-standard HTTP header, from a reserved > field value that means redacted (a single space, perhaps) to adding > IS-REDACTED flags to the components that might be affected. I thought we were doing REST, not REST-except-where-everything-is-inlined-then-work-hard? We can't possibly be the only people on earth who want to offer different views of the same data depending on the credentials of the query source. The natural way to do that is surely not "bodge up the data so you have to parse it to know what it means". One of the things that hosed IRIS, I think, was the difficulty on the client side. If the plan here is that we need to make the clients smart enough to tell the metadata from the data by parsing it, I would like to suggest that we'll fail again. DNS has now a 25 year hangover from the fact that the control plane and the data plane are not clearly delineated, and I really don't see a reason to repeat that mistake. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From andy@arin.net Tue Jun 12 13:41:17 2012 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 283A111E80B1 for ; Tue, 12 Jun 2012 13:41:17 -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 xYjwTbq7fBY2 for ; Tue, 12 Jun 2012 13:41:16 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 60E9111E80AC for ; Tue, 12 Jun 2012 13:41:16 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id D3C20165030; Tue, 12 Jun 2012 16:41:15 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 70A4F165003; Tue, 12 Jun 2012 16:41:15 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 12 Jun 2012 16:40:59 -0400 Received: from [10.1.0.49] (10.1.0.49) by CHAXCH03.corp.arin.net (10.1.30.23) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 12 Jun 2012 16:41:08 -0400 Message-ID: <4FD7A964.6040801@arin.net> Date: Tue, 12 Jun 2012 16:41:08 -0400 From: Andy Newton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20120612155643.GI16548@mail.yitter.info> <20120612202423.75669.qmail@joyce.lan> <20120612203425.GO25201@mail.yitter.info> In-Reply-To: <20120612203425.GO25201@mail.yitter.info> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.0.49] Cc: weirds@ietf.org Subject: Re: [weirds] decomposition and redaction, was FW: I-D Action 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, 12 Jun 2012 20:41:17 -0000 On 06/12/2012 04:34 PM, Andrew Sullivan wrote: > I thought we were doing REST, not > REST-except-where-everything-is-inlined-then-work-hard? We can't > possibly be the only people on earth who want to offer different views > of the same data depending on the credentials of the query source. > The natural way to do that is surely not "bodge up the data so you > have to parse it to know what it means". > > One of the things that hosed IRIS, I think, was the difficulty on the > client side. If the plan here is that we need to make the clients > smart enough to tell the metadata from the data by parsing it, I would > like to suggest that we'll fail again. DNS has now a 25 year hangover > from the fact that the control plane and the data plane are not > clearly delineated, and I really don't see a reason to repeat that > mistake. How is forcing a client to requery 3 or 4 times less cumbersome? I use to believe as you do, but experience has taught me differently. -andy From ajs@anvilwalrusden.com Tue Jun 12 13:58:17 2012 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 EADB411E80D7 for ; Tue, 12 Jun 2012 13:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEcqUOHFBqL8 for ; Tue, 12 Jun 2012 13:58:16 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2849F11E80CE for ; Tue, 12 Jun 2012 13:58:15 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3EC881ECB41C for ; Tue, 12 Jun 2012 20:58:15 +0000 (UTC) Date: Tue, 12 Jun 2012 16:58:13 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120612205813.GR25201@mail.yitter.info> References: <20120612155643.GI16548@mail.yitter.info> <20120612202423.75669.qmail@joyce.lan> <20120612203425.GO25201@mail.yitter.info> <4FD7A964.6040801@arin.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FD7A964.6040801@arin.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] decomposition and redaction, was FW: I-D Action 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, 12 Jun 2012 20:58:17 -0000 On Tue, Jun 12, 2012 at 04:41:08PM -0400, Andy Newton wrote: > How is forcing a client to requery 3 or 4 times less cumbersome? I am not trying to make a client requery 3 or 4 times. I'm trying to ensure that we have the basic elements in place so that we can actually offer the things we said we would. This might mean additional URIs so that it is easy to combine results. But as I read REST, you should start with the atoms and work out. Even if nobody ever uses the atomic bits. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From andy@arin.net Tue Jun 12 14:04:59 2012 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 60D0221F86E8 for ; Tue, 12 Jun 2012 14:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAkrovYXlnNv for ; Tue, 12 Jun 2012 14:04:59 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id C289A21F86B4 for ; Tue, 12 Jun 2012 14:04:58 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 4115221365E; Tue, 12 Jun 2012 17:04:58 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id E18412135F2; Tue, 12 Jun 2012 17:04:57 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Tue, 12 Jun 2012 17:04:19 -0400 Received: from [10.1.0.49] (10.1.0.49) by CHAXCH03.corp.arin.net (10.1.30.23) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 12 Jun 2012 17:04:57 -0400 Message-ID: <4FD7AEF9.7050503@arin.net> Date: Tue, 12 Jun 2012 17:04:57 -0400 From: Andy Newton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Andrew Sullivan References: <20120612155643.GI16548@mail.yitter.info> <20120612202423.75669.qmail@joyce.lan> <20120612203425.GO25201@mail.yitter.info> <4FD7A964.6040801@arin.net> <20120612205813.GR25201@mail.yitter.info> In-Reply-To: <20120612205813.GR25201@mail.yitter.info> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.0.49] Cc: weirds@ietf.org Subject: Re: [weirds] decomposition and redaction, was FW: I-D Action 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, 12 Jun 2012 21:04:59 -0000 On 06/12/2012 04:58 PM, Andrew Sullivan wrote: > I am not trying to make a client requery 3 or 4 times. I'm trying to > ensure that we have the basic elements in place so that we can > actually offer the things we said we would. This might mean > additional URIs so that it is easy to combine results. But as I read > REST, you should start with the atoms and work out. Even if nobody > ever uses the atomic bits. We may have reached a point where we are talking past each other here. In the context of the RIR-JSON draft, can you provide a concrete example for the need for additional URIs in a manner that is already not provided? And where redaction and a redaction-happened-flag are not adequate? -andy From ebw@abenaki.wabanaki.net Tue Jun 12 14:25:08 2012 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 62E5D21F86E8 for ; Tue, 12 Jun 2012 14:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wO5qYMdJjkwr for ; Tue, 12 Jun 2012 14:25:07 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id B63FD21F86E5 for ; Tue, 12 Jun 2012 14:25:07 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5CIHYHq067472 for ; Tue, 12 Jun 2012 14:17:34 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FD7B3AC.5030705@abenaki.wabanaki.net> Date: Tue, 12 Jun 2012 17:25:00 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] policy & tech (last one) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 21:25:08 -0000 i'm busy moving my household and generally ignoring work, however ... to bob. earlier someone employed by icann, if i understood him correctly, tried to make the case that a mechanism allowing authentication and services which scope the delivery of query responses, e.g., content, rate, etc., ought not be included in the protocol. i tried to point out that the absence of such a mechanism has scaling consequences as there are order 10^^5, even 10^^6 query originators (aka "botnets") whos intended use is to publish (to a set of recipients) substantial subsets of the entire registration database for any particular zone. registrants are generally opposed to this, and in the icann contractual regime, registrars and registries are not obliged to provide bulk access unconditionally -- as you know, and outside of that private contractual set of data originators and managers, the several public regulatory regimes contain at least one -- the eu -- in which unconditional access is deprecated. we seem to have gotten past that point in mechanism or policy with an agreement that a mechanism allowing some form of response scoping will be present in the protocol. if someone "turns it off", the 10^^N problem is his or hers to enjoy. so to respond on-list to bob, with whom i shared a naralo participation in 2010/2011, existence of a mechanism is not a policy decision. mechanism allow policy, singular and plural. absence of a mechanism allowing data scoping is a data model of universality, as anyone in the dns community is aware of -- restrictions on scope has meaning. i know this will gall, but in my view, no you are not a "part of the community as much as anyone else" -- you are a data consumer, and with a smaller set of interests than the data custodial interests, motivated by private gain or a competing theory of public interest, of registry operators and registrar operators and post-43-server and post-43-client implementers, who are attempting still the difficult task of agreeing to a specification. -e From bje@apnic.net Tue Jun 12 19:01:34 2012 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 AA14221F872A for ; Tue, 12 Jun 2012 19:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC45ppKjv2eQ for ; Tue, 12 Jun 2012 19:01:34 -0700 (PDT) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id AA5FA21F8724 for ; Tue, 12 Jun 2012 19:01:32 -0700 (PDT) Received: from [IPv6:2001:dc0:a000:4:2c8b:6c18:6cf4:7799] (unknown [IPv6:2001:dc0:a000:4:2c8b:6c18:6cf4:7799]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 9D187B684D; Wed, 13 Jun 2012 12:01:29 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_1F0C379C-6DA4-45F5-A958-C0789588C5EE"; protocol="application/pkcs7-signature"; micalg=sha1 From: Byron Ellacott In-Reply-To: Date: Wed, 13 Jun 2012 12:01:29 +1000 Message-Id: References: To: Bob Bruen X-Mailer: Apple Mail (2.1257) Cc: weirds@ietf.org Subject: Re: [weirds] policy & tech 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, 13 Jun 2012 02:01:34 -0000 --Apple-Mail=_1F0C379C-6DA4-45F5-A958-C0789588C5EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13/06/2012, at 4:51 AM, Bob Bruen wrote: > That is a policy decision. By adding capabilities to anything you = create its potential use. By deciding not to add, you are denying its = use. Either way, it's a policy decision at an early stage and it should = be considered carefully. This particular capability is chosen and = another is not. Why pick one and not another? To pick up on this question - this particular capability is chosen = because it is an expressed need of subjects, consumers, operators, and = regulators of Whois services. See SAC 051, or the now ancient ICANN = WHOIS Service Requirements document, or the perhaps less applicable but = still informative RFC 3707 CRISP requirements work. This requirement is in draft-kucherawy-weirds-requirements, section 3.2, = if you wanted to address the reasoning given there or propose new text = to replace that section with a requirement for no differentiation of = service. Byron [speaking for myself]= --Apple-Mail=_1F0C379C-6DA4-45F5-A958-C0789588C5EE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEBjCCBAIw ggLqoAMCAQICCCoPITf60ZNDMA0GCSqGSIb3DQEBBQUAMHMxETAPBgNVBAMMCHN0YWZmLWNhMRIw EAYDVQQLDAlUZWNobmljYWwxFjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNi YW5lMRIwEAYKCZImiZPyLGQBGRYCY2ExCzAJBgNVBAYTAkFVMB4XDTExMTEyODAxNTEzNloXDTEy MTEyNzAxNTEzNlowgZIxGTAXBgoJkiaJk/IsZAEBDAliamUtc3RhZmYxEjAQBgNVBAMMCWJqZS1z dGFmZjEOMAwGA1UEKgwFQnlyb24xETAPBgNVBAQMCEVsbGFjb3R0MQ8wDQYDVQQLDAZQZW9wbGUx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxFTATBgoJkiaJk/IsZAEZFgVzdGFmZjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANVQo/BOmY5CCWNeAldlgoWZKOzIZpOsFzD6NB2oAErtclDu uiZsXfl+L97UOwUlhu1eGlY5gKuAhGcrEBvDgTT1eEr3vkdKILhJw78s5n8eLOWrmhPKBnW8gSn9 7MbAxVQx3V1/RpToKAF8cR4il03Z7mveaBQbaivM2jReHcgfJPt9w0qhTVZO2POLuVClRcExaNt1 h+QdMLa6VU5x7rJo9JFqjTAvJzMApW+WY/7oumR9+4a9ZGThlETI2b83XAMrrJ7DHm237Jskgl+X FGILIq8zOhNiAbhEg+gAyJ8bOzwwydDY+ggWQ466duZZq4wxmr1+YhxVf51v2R5MSicCAwEAAaN6 MHgwHQYDVR0OBBYEFIQXSivz3cLpaFy23DdhpGhyyo5pMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgw FoAU4D23klvuLqOyPnnbRaswQi8BS6wwDgYDVR0PAQH/BAQDAgHyMBgGA1UdEQQRMA+BDWJqZUBh cG5pYy5uZXQwDQYJKoZIhvcNAQEFBQADggEBAEk9zi8BTUEY4rqDGEIFDNIpmX/yS3fTah39Mele pV93sRsjqLy2G47vhhnkgSTEWV2jJOD7tjzjswxtWUL6KG36dUDVL3XbQ1OObxkiDJbqje4BoWrd a8/5PoIPC0hkSDXGoitvoXkL8Pd9x9Y+kyMlKo1C0lk5bCUG4yjk5wVLuSSm5m+KZ3+YVdPp6dKp C0DRhvFdsrz2zIOT/sWheCQO0HRU300UYngB/xoqc1KWH2dROIUhLqwtyoCQbQKQjW9C+JMMw2Ij vfVXJZGMWjbp5l8RQeUSJ+0vVJXJbIL6PfEsyQupUV3AJsSTRmtllqzCBCz2Abd14xyeqw0eJfwx ggMtMIIDKQIBATB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwxFjAU BgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQBGRYC Y2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzAJBgUrDgMCGgUAoIIBgzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA2MTMwMjAxMzBaMCMGCSqGSIb3DQEJBDEWBBSU wmUaeMgsrcamIpLu8HYSpaE+TTCBjwYJKwYBBAGCNxAEMYGBMH8wczERMA8GA1UEAwwIc3RhZmYt Y2ExEjAQBgNVBAsMCVRlY2huaWNhbDEWMBQGA1UECgwNQVBOSUMgUHR5IEx0ZDERMA8GA1UEBwwI QnJpc2JhbmUxEjAQBgoJkiaJk/IsZAEZFgJjYTELMAkGA1UEBhMCQVUCCCoPITf60ZNDMIGRBgsq hkiG9w0BCRACCzGBgaB/MHMxETAPBgNVBAMMCHN0YWZmLWNhMRIwEAYDVQQLDAlUZWNobmljYWwx FjAUBgNVBAoMDUFQTklDIFB0eSBMdGQxETAPBgNVBAcMCEJyaXNiYW5lMRIwEAYKCZImiZPyLGQB GRYCY2ExCzAJBgNVBAYTAkFVAggqDyE3+tGTQzANBgkqhkiG9w0BAQEFAASCAQAvWoEqTXcGaphn XFpui1ENu4kOFPZmjOao9nNHwegXaJjLQd3OJkvAqXm9p8BzruLbJEIUmrGUZsPdHMG/EBeoE0/m fKy8dTkREWBlU9oiLbk1PbpfAyAP6ftF9P+0wuO27uLZnafVo7FWrQbI029JWBIsKHDh99JQi/ss bAkH0hYnVYpjgt5mRo/aME93QK3WDWtd+YJdMHCmmdn2otRd14jFY67yGVTT5mS7QrjCw9AIfX9p berfJmCXuCB5s+Nu/8oYxZZTVNVk9QM9zFJ2/ukZr/yeSSN/n81KKhYYx+J19bgDOmLenn7/ko5i 8RbcA7BYqcJ7MvtiiuC/F70EAAAAAAAA --Apple-Mail=_1F0C379C-6DA4-45F5-A958-C0789588C5EE-- From zhoulinlin@cnnic.cn Tue Jun 12 20:29:27 2012 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 A7FC421F86B2 for ; Tue, 12 Jun 2012 20:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13W0l5zH-JmS for ; Tue, 12 Jun 2012 20:29:27 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 8ADF021F8647 for ; Tue, 12 Jun 2012 20:29:24 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 13 Jun 2012 11:29:15 +0800 From: "Linlin Zhou" To: "'Andrew Sullivan'" , References: <20120603071136.21782.19013.idtracker@ietfa.amsl.com> <014601cd415c$01bf3fc0$053dbf40$@cnnic.cn> <4FD6D3E2.5050707@vande-walle.eu> <00ef01cd48a4$58b44ce0$0a1ce6a0$@cnnic.cn> <20120612144223.GF16548@mail.yitter.info> In-Reply-To: <20120612144223.GF16548@mail.yitter.info> Date: Wed, 13 Jun 2012 11:29:15 +0800 Message-ID: <008d01cd4914$b5ab2c00$21018400$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1IqZnDAztpV+0WT3+o8YDdcOx9tAAYeRRA Content-Language: zh-cn Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 03:29:27 -0000 Hi, Thanks for comments. This draft intends to specify the common response format. So we put more focus on the technical part. In this version, just a brief paragraph before section 3.1 is provided related to policy. Having read the policy & tech thread, IMHO, both the authentication mechanism and policy making will affect the query and response drafts. The authentication mechanism supplies the technical solution, and policy decisions raise the specific requirements. Until now ,at least I am not quite clear about the authentication mechanism that will be adopted and the specific requirements for differential classes of service. So, I think the above work should be done in parallel, in which way, the protocol could be improved better. We have done some research wok on authentication, but need more help and contribution from experts on web authentication and security. We also welcome more comments from policy experts, providing some specific requirements for the draft. Thanks & regards, Linlin Zhou CNNIC > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Andrew Sullivan > Sent: Tuesday, June 12, 2012 10:42 PM > To: weirds@ietf.org > Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt > > On Tue, Jun 12, 2012 at 10:04:55PM +0800, Ning Kong wrote: > > > I think you put forward a general issue. IMO, the HTTP draft > > (draft-designteam-weirds-using-http-00) as the common infrastructure > > document is suitable to cover this point. For example, a new section (e.g. > > 5.5 Unauthorized Answers) may be added to propose the corresponding > > response mechanisms. > > This raises an interesting and vexing issue, I think. > > As we're working now, we are talking about responses and requests. > But in a REST context, it seems to me, you either get the resource or you don't. > > One of the goals so far has been to permit differential levels of service > depending on credentials. (I believe quite strongly that if we do not provide > that functionality, we will have completely botched this work.) > > It seems to me therefore that data we return must be much more linked and > much less cohesive. For instance, in the present draft, the response for > domains includes contact data, nameserver data, and so on. But instead, > that all ought to be linked data, so that it is possible to return the appropriate > response (e.g. the data vs. http > 401 or 403 errors) depending on who asks for it. It seems also that it might > be possible to create a roll-up type resource that provides all the answers in > one go, at the cost of authorization being the denied if any of the underlying > resource permissions aren't available. > > Thoughts? > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nkong@cnnic.cn Wed Jun 13 02:52:01 2012 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 8200421F86E8 for ; Wed, 13 Jun 2012 02:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 9+EjEe+8fNRB for ; Wed, 13 Jun 2012 02:51:58 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id E556F21F86C8 for ; Wed, 13 Jun 2012 02:51:52 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn Received: from unknown127.0.0.1 (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 13 Jun 2012 17:51:44 +0800 From: "Ning Kong" To: "'Steve Sheng'" , "'Olaf Kolkman'" , "'Web Extensible Internet Registration Data Service Working Group'" References: In-Reply-To: Date: Wed, 13 Jun 2012 17:51:37 +0800 Message-ID: <01b501cd494a$20482920$60d87b60$@cnnic.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B6_01CD498D.2E702410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLNlh8sUKeeHdyG/gXyA+qUl6D+6ZT3PR0Q Content-Language: zh-cn Subject: Re: [weirds] Divide and Conquer 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, 13 Jun 2012 09:52:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B6_01CD498D.2E702410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Steve, Thanks for your contribution! I hope this work can be continued and I'd like to join. I believe the output of this work can help us to improve the response draft (e.g. finding out some better names for terms of objects, and even specifying an absolutely minimum data element set in a response). Cheers, Ning From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Steve Sheng Sent: Wednesday, June 13, 2012 2:39 AM To: Olaf Kolkman; Web Extensible Internet Registration Data Service Working Group Subject: Re: [weirds] Divide and Conquer Hello Olaf and all, From: Olaf Kolkman To: Web Extensible Internet Registration Data Service Working Group Subject: [weirds] Divide and Conquer Dear Colleagues, Murray and myself have been talking to a few active working participants, with the area director, and among ourselves. Based on those discussion, and after coordination with Murray, I would like to make two proposals for getting work done: 1. Working group drafts and output documents. Murray has already called for adaption of a number of documents. Those documents are all input documents. The output of the working group might find its way into a different set of documents. A structure that has been proposed to me by Scott H. and Andy N. seems reasonable: 1. For all implementers: 1.1 The use of HTTP 1.2 Details of Redirecting 1.3 Specification of generic json responses and extensibility mechanism 1.4 Specification of generic xml responses and extensibility mechanism 2.Numbers: 2.1 specification of queries 2.2 specification of specific number-responses json responses 3.Names: 3.1 specification of queries 3.2 specification of specific name-related json responses and/or 3.3 specification of specific number-related xml responses It might be that 1.3 and 1.4 are so minimal that the information therein is better (dublicated) in 2.2, 3.2, and 3.3. 2. Dealing with the data framework. I believe that the data framework for the domain name space is one of the biggest elephants in the room and that making sure we converge to a comon understanding is critical to success of the working group. It seems that an enumeration of all data elements that are comonly in use including comonly used formats. Ray Bellis and Frederico Neves have made a start with that in a spreadsheet at https://docs.google.com/spreadsheet/ccc?key=0AjZQpmBlboLWdFBfdERTQm9QQWdrejN taTBhNmI3SHc#gid=0 and it seems that we can use that as a basis. I have done an inventory of the data elements that current gTLD registries' Registration Data Directory Service (RDDS) output. Attached please find the spreadsheet. This inventory contains 159 data elements that are: - actual RDDS output of 18 gTLD registries - new gTLD RDDS output as specified by ICANN applicant guidebook Among these 159 data elements, 75 are common elements, 84 are registry specific elements. This distinction is also highlighted in the excel sheet. Finally, I have also harmonized data labels from different gTLD registries that refer to the same element. Note, the scope of this exercise is limited to domain queries for gTLD registries, it does not cover querying name server and registrars, nor does it cover registrar RDDS in the case of thin registries. If people find this preliminary exercise useful, I can continue to work on this, and also invite others to participate to get this done for gTLDs as well as ccTLDs. Steve Once we have a relatively complete enumeration of all data elements that are commonly in use we continue with trying to get convergence on their presentation format (it seems we have to do that irrespective of encaptulation in json or xml). One of the important questions that might help to converge while defining data elements and while determining such data-element can be queried is whether the query-response protocol is direct match, or search. The charter is not clear about this, I believe. Hence I propose that we focus on the low-hanging fruit of direct-match and that we circumvent any questions of the type 'what type of matching algorithm to apply?' For instance, if we have a person name as a data element then a query for "Kolkman" might not yield a unique result and some matching algorithm may need to be applied, the use of a NIC-handle might be more appropriate in such cases. By agreeing on the principle that we work towards direct-match we know how to focus our energy. How does this sound as a first order approach? If folk like this we'll try to come up with a way to capture the information in the spreadsheet (or other appropriate tool) and work forward in a structured way. --Olaf WEIRDS co-chair NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands ------=_NextPart_000_01B6_01CD498D.2E702410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Steve,

 <= /span>

Thanks for your = contribution! I hope this work can be continued and I’d like to = join.

I believe the = output of this work can help us to improve the response draft (e.g. = finding out some better names for terms of objects, and even specifying = an absolutely minimum data element set in a = response).

 <= /span>

 <= /span>

Cheers,=

Ning

 <= /span>

From:= = weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of = Steve Sheng
Sent: Wednesday, June 13, 2012 2:39 = AM
To: Olaf Kolkman; Web Extensible Internet Registration Data = Service Working Group
Subject: Re: [weirds] Divide and = Conquer

 

Hello Olaf and all, 

 

From: Olaf Kolkman <olaf@nlnetlabs.nl>
To: = Web Extensible Internet Registration Data Service Working Group = <weirds@ietf.org>
Subject: = [weirds] Divide and Conquer

 

 

Dear Colleagues,

 

Murray and myself have been talking to a few active working = participants, with the area director, and among = ourselves. 

 

Based on those discussion, and after coordination with Murray, I = would

like to make two proposals for getting work = done:

 

 

1. Working group drafts and output = documents.

 

Murray has already called for adaption of a number of documents. = Those

documents are all input documents. The output of the working = group

might find its way into a different set of = documents.

 

A structure that has been proposed to me by Scott H. and Andy N. seems = reasonable: 

 

1. For all implementers:

  1.1 The use of HTTP

  1.2 Details of Redirecting

 

  1.3 Specification of generic json responses and extensibility = mechanism

  1.4 Specification of generic xml responses and extensibility = mechanism

 

2.Numbers:

  2.1 specification of queries

  2.2 specification of specific number-responses json = responses

 

3.Names:

  3.1 specification of queries

  3.2 specification of specific name-related json = responses 

and/or

  3.3 specification of specific number-related xml = responses

 

 

It might be that 1.3 and 1.4 are so minimal that the = information

therein is better (dublicated) in 2.2, 3.2, and = 3.3.

 

 

 

2. Dealing with the data framework.

 

I believe that the data framework for the domain name space is one = of

the biggest elephants in the room and that making sure we converge = to

a comon understanding is critical to success of the working group. = It

seems that an enumeration of all data elements that are comonly in = use

including comonly used formats. Ray Bellis and Frederico = Neves

have made a start with that in a spreadsheet = at

 

I have done an inventory of the data elements that current gTLD = registries' Registration Data Directory Service (RDDS) = output. 

 

Attached please find the spreadsheet. This inventory contains 159 = data elements that are: 

  - actual RDDS output of 18 gTLD = registries

  - new gTLD RDDS output as specified by ICANN applicant = guidebook 

 

Among these 159 data elements, 75 are common elements,  84 are = registry specific elements. This distinction is also highlighted in the = excel sheet. 

 

Finally, I have also harmonized  data labels from different gTLD = registries that refer to the same element. =  

 

Note, the scope of this exercise is limited to domain queries for gTLD = registries, it does not cover querying name server and registrars, nor = does it cover registrar RDDS in the case of thin registries. If people = find this preliminary exercise useful, I can continue to work on this, = and also invite others to participate to get this done for gTLDs as well = as ccTLDs.  

 

Steve

 

<= p class=3DMsoNormal> 

Once we have a relatively complete enumeration of all data = elements

that are commonly in use we continue with trying to get convergence = on

their presentation format (it seems we have to do that irrespective = of

encaptulation in json or xml).

 

One of the important questions that might help to converge = while

defining data elements and while determining such data-element can = be

queried is whether the query-response protocol is direct match, = or

search. The charter is not clear about this, I believe. Hence = I

propose that we focus on the low-hanging fruit of direct-match = and

that we circumvent any questions of the type 'what type of = matching

algorithm to apply?' 

 

For instance, if we have a person name as a data element then a = query

for "Kolkman" might not yield a unique result and some = matching

algorithm may need to be applied, the use of a NIC-handle might = be

more appropriate in such cases. By agreeing on the principle that = we

work towards direct-match we know how to focus our = energy.

 

How does this sound as a first order approach? If folk like this = we'll

try to come up with a way to capture the information in the = spreadsheet

(or other appropriate tool) and work forward in a structured = way.

 

--Olaf 

  WEIRDS = co-chair

 

 = ;

NLnet
Labs

Olaf M. Kolkman

Science Park 400, 1098 XH Amsterdam, The Netherlands

 

 

 

------=_NextPart_000_01B6_01CD498D.2E702410-- From bob@coldrain.net Wed Jun 13 06:19:06 2012 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 15FDF21F867E for ; Wed, 13 Jun 2012 06:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhA+7MlU8NHL for ; Wed, 13 Jun 2012 06:19:05 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7992021F8642 for ; Wed, 13 Jun 2012 06:19:05 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5DDJ2Mk018388 for ; Wed, 13 Jun 2012 09:19:02 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5DDJ2V4018384 for ; Wed, 13 Jun 2012 09:19:02 -0400 Date: Wed, 13 Jun 2012 09:19:02 -0400 (EDT) From: Bob Bruen To: weirds@ietf.org Message-ID: User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [weirds] lessons learned 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, 13 Jun 2012 13:19:06 -0000 Hi, This is been a learning experience for me. I have been around for a long time and it appears I missed some important changes. I was working under the old IETF model, where if you showed up, you were part of the process. The important thing was to get it right. It was a thoughtful time. Now, it seems that the agenda of special interest groups run the process. I am not part of "the community" because I am considered a "data consumer" and in this case the "data providers" are running the show. The agenda has been set. Now it just gets implemented. --bob From johnl@iecc.com Wed Jun 13 07:57:19 2012 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 4E1BD21F85A0 for ; Wed, 13 Jun 2012 07:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgG3OFKFOhkh for ; Wed, 13 Jun 2012 07:57:18 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 92F9521F8593 for ; Wed, 13 Jun 2012 07:57:18 -0700 (PDT) Received: (qmail 16947 invoked from network); 13 Jun 2012 14:57:16 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jun 2012 14:57:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fd8aa4c.xn--hew.k1206; i=johnl@user.iecc.com; bh=+dw9ucSi4M9lyMOxamyVAeFMrB+JU+6viFdDo29Qw5g=; b=bYnaiKqVn47922f54Ovw4CFxNSRYmno0Oho7nYEOC7Y5y78Qs+x4x3fYL1xIkcMiCuuTi2ahQw86PSr4vF7a67L/q9fysrj/a2WEsoxzBAhBHmIRm7whiHFuPnbOcnW0pB4SmHwFOC+it8PFqc8/t3F9UsyqFQaAi6oG+QuYzHw= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Jun 2012 14:56:53 -0000 Message-ID: <20120613145653.62974.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] Divide and Conquer 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, 13 Jun 2012 14:57:19 -0000 >I have done an inventory of the data elements that current gTLD registries' >Registration Data Directory Service (RDDS) output. Thanks, this is very helpful. Any chance of a similar comparison of the query types the various TLDs support? The specs in the various registry agreements are susprisingly divergent. R's, John From AMaitland@Commerco.Com Wed Jun 13 08:31:46 2012 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 CC24A21F866C for ; Wed, 13 Jun 2012 08:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 thxKM5I4kEH0 for ; Wed, 13 Jun 2012 08:31:46 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id F24CC21F8657 for ; Wed, 13 Jun 2012 08:31:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=opowuIJXS5wjEU5qsx2pNYBz469b2ymmOyXjHIaZAzoLGM0Q6nJouVGbC4snYbHdSusV8QpxUhSSgopsN0I2IUNTKP0oUYfJOh1qUm1p3f/9cpzNBFzar3uJdkTKic8ju3S4c/ZP67wdOB+0UWWAihHFQumvIj1ht/1qQ0J6PWc= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Wed, 13 Jun 2012 15:31:42 +0000 Message-ID: <4FD8B258.8060806@Commerco.Com> Date: Wed, 13 Jun 2012 09:31:36 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] lessons learned 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, 13 Jun 2012 15:31:47 -0000 Dr. Bruen, Speaking also as a "data consumer" (in Mr. Brunner-William's perhaps gruff, if not regrettable parlance) on this list, I'm here to suggest to you that your original premise may simply not be right for the times. Your original list post: --- IMHO, there should not be a different service depending on credentials. The original whois presented all the available data, then the amount was cut back. It should be like the original, so that all the data is available to anyone. --- The problem with this thinking is that there may well be data that is arguably just inappropriate to share with "the community" for a variety of reasons. Planning for such a design viewpoint as varied data feeds seems not at all inappropriate for a contemporary standards body list. For example, perhaps there is some data that might make its way into the system that is used by various registries who may or may not wish or be able to share the data with the general consumer population, while making sense or being legally allowed to share between registries. A reason it might not make sense to generally provide the data could certainly relate to matters involving legal or law enforcement matters. You might not like it, but the legal systems and laws of different nations can make the need for such things as data selectivity a requirement in certain nations, so planning to succeed by allowing for such requirements will logically include as many nations as possible and thus assist in assuring a maximized adoption rate for any standard du jour. As you have been around for a long time, you understand that the Internet has changed radically in the last 20 years. The days of a tightly knit community with the admirable intent to "do the right thing" has, perhaps sadly, evolved. Pretty much the rest of the known universe has now joined with online and as such, increased numbers of less savory (though quite creative) types are now part of the package. This reality causes the way many would like things to evolve to also change to accommodate the Internet's new normal. Because of the size and dependance on the Internet, "getting it right" the first time is even more critical than ever. I would argue that the thoughtfulness you mentioned below needs to be even greater today than in the earlier days because of the significantly increased complexity caused by both technical and non-technical considerations. Another thought... As you probably have observed, the bad guys often enough actually depend upon total openness of the Internet and sometimes that makes the total openness model somewhat inappropriate. I don't attend the various (name your acronym) meetings, though I do observe and contribute where I can to some online lists that I either find of interest or have a need to observe for company business reasons. I too have been around a while and think that things regarding the ways in which standards evolve overall have really not changed that much (though by necessity, the process has become a bit more formalized). I have also observed that folks involved in standard's bodies do indeed continue to tend to respond fairly well to inputs from nearly anyone, especially so, those inputs which are presented in a clear and concise manner. So, given what you have shared of your lessons learned, of course you and I are both part of the broader Internet community. That said however, while the registry communities (both domain name and IP) are willing to accept inputs from either of us, neither of us are part of that subset community per se in any other capacity than that of a consumer. That is not a bad thing, it is just a reality. Personally, I appreciate that the process itself continues to be so entirely open to the public and that feedback continues to be taken by the registry community from anyone as a part of the process. Respectfully, Alan Maitland On 6/13/2012 7:19 AM, Bob Bruen wrote: > > Hi, > > This is been a learning experience for me. I have been around for a long > time and it appears I missed some important changes. I was working under > the old IETF model, where if you showed up, you were part of the > process. The important thing was to get it right. It was a thoughtful time. > > Now, it seems that the agenda of special interest groups run the > process. I am not part of "the community" because I am considered a > "data consumer" and in this case the "data providers" are running the > show. The agenda has been set. Now it just gets implemented. > > --bob > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > From johnl@iecc.com Wed Jun 13 08:59:06 2012 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 36BB621F8562 for ; Wed, 13 Jun 2012 08:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeywKV0AU49v for ; Wed, 13 Jun 2012 08:59:05 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4B21F857A for ; Wed, 13 Jun 2012 08:59:05 -0700 (PDT) Received: (qmail 27404 invoked from network); 13 Jun 2012 15:59:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Jun 2012 15:59:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fd8b8c8.xn--30v786c.k1206; i=johnl@user.iecc.com; bh=axjb9x5WRd7H7EGGTl4upGf39jp7oOscCJ2Ddiqjp1o=; b=p7B0F0X4b+iSARu31Nf7OSe9Pz1vUgktZvEzDwO4BDfJ0TGHbavsCXYnMqY1bKbKMAr7KDoIugwToelRDgUVhP508deoOg5kF3ZaylWcnh1Hs6B0s6duVIPRB4TUDwUtT3yDIgyadqZ+hPU6kk1C8YKAvKwFro0mAjXgciPvMgI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 13 Jun 2012 15:58:41 -0000 Message-ID: <20120613155841.77939.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] lessons learned 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, 13 Jun 2012 15:59:06 -0000 > Now, it seems that the agenda of special interest groups run the > process. I am not part of "the community" because I am considered a > "data consumer" and in this case the "data providers" are running the > show. ... I'm sorry, but this totally misunderstands what standards are and what they can do. All an IETF standard can do is tell people how to interoperate if they are already inclined to do so. WEIRDS can say here's how a client can send a query that a server will understand, and here's how a server can send a response that a client can parse. That's it. Much though I would like to say the servers MUST answer all queries without rate limiting and MUST NOT respond with redacted versions of cruddy data, that's not how it works. Were we to say that, either the servers would ignore those parts and rate limit and redact anyway, most likely in ways that made it impossible for clients to tell what's going on, or else would say that since WEIRDS doesn't let us follow our policies, we can't use WEIRDS. Having written a WHOIS scraper that is over 2700 lines and still growing, I'm acutely aware of how badly WHOIS works. A mechanically queryable version of what we have now, while still far from ideal, would be a considerable improvement. There are other places to have policy arguments. This isn't one. R's, John From steve.sheng@icann.org Wed Jun 13 09:05:05 2012 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 78B7921F85C2 for ; Wed, 13 Jun 2012 09:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=0.699, 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 TLn5MJ3nVqlU for ; Wed, 13 Jun 2012 09:05:05 -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 A03BE21F861F for ; Wed, 13 Jun 2012 09:05:03 -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; Wed, 13 Jun 2012 09:05:00 -0700 From: Steve Sheng To: John Levine , "weirds@ietf.org" Date: Wed, 13 Jun 2012 09:04:58 -0700 Thread-Topic: [weirds] Divide and Conquer Thread-Index: Ac1JfkkItVI9HZ7TSgeiwqoTmg1J0g== Message-ID: In-Reply-To: <20120613145653.62974.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422423098_9263511" MIME-Version: 1.0 Subject: Re: [weirds] Divide and Conquer 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, 13 Jun 2012 16:05:05 -0000 --B_3422423098_9263511 Content-type: multipart/mixed; boundary="B_3422423098_9271252" --B_3422423098_9271252 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello John, -----Original Message----- From: John Levine To: "weirds@ietf.org" Cc: Steve Sheng Subject: Re: [weirds] Divide and Conquer >>I have done an inventory of the data elements that current gTLD >>registries' >>Registration Data Directory Service (RDDS) output. > >Thanks, this is very helpful. Any chance of a similar comparison of the >query types the various TLDs support? The specs in the various registry >agreements are susprisingly divergent. Attached please find the analysis that I sent to the list earlier. > >R's, >John --B_3422423098_9271252 Content-type: application/x-msexcel; name="2012 gTLD registry WHOIS Service.xls"; x-mac-creator="5843454C"; x-mac-type="584C5338" Content-disposition: attachment; filename="2012 gTLD registry WHOIS Service.xls" Content-transfer-encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAAQAAAAAA AAAAEAAAOwAAAAEAAAD+////AAAAAAAAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////9////RgAAAAMAAAAEAAAABQAAAAYAAAAHAAAA CAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAA AAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAA/v////7////+//// PgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAAD+/////v////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////1IA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAACAAUA//////////8CAAAAIAgCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAPD8 gFQmKs0BPAAAAIABAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEEAAAA//////////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAkHEAAAAAAAAFAFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQEA AAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD0AAAAEEQAA AAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkA bwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAPQAAAAAAAAACQgQAAAGBQDZVMwHAAADAAYGAADhAAIAsATBAAIA AADiAAAAXABwAAsAAFN0ZXZlIFNoZW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCAAIAsARhAQIAAAA9AQIAAQCcAAIAEQAZAAIAAAASAAIAAAATAAIA AACvAQIAAAC8AQIAAAA9ABIAAAAAAACWyEY4AAAAAAABAPQBQAACAAAAjQACAAAAIgACAAAA DgACAAEAtwECAAAA2gACAAAAMQAeAPAAAAAIAJABAAAAAgBfBwFDAGEAbABpAGIAcgBpADEA HgDwAAAACACQAQAAAAIAXwcBQwBhAGwAaQBiAHIAaQAxAB4A8AAAAAgAkAEAAAACAF8HAUMA YQBsAGkAYgByAGkAMQAeAPAAAAAIAJABAAAAAgBfBwFDAGEAbABpAGIAcgBpADEAHgDwAAAA CACQAQAAAAIAXwcBQwBhAGwAaQBiAHIAaQAxABoAGAEAAAgAkAEAAAAAAF8FAUEAcgBpAGEA bAAxABoAGAEAAAgAkAEAAAAAAF8FAUEAcgBpAGEAbAAxAB4A8AAEAAwAkAEAAAECAAAHAUMA YQBsAGkAYgByAGkAMQAeAPAABAAUAJABAAABAgAABwFDAGEAbABpAGIAcgBpADEAHgBoAQEA OAC8AgAAAAIAAAcBQwBhAG0AYgByAGkAYQAxAB4ALAEBADgAvAIAAAACAAAHAUMAYQBsAGkA YgByAGkAMQAeAAQBAQA4ALwCAAAAAgAABwFDAGEAbABpAGIAcgBpADEAHgDcAAEAOAC8AgAA AAIAAAcBQwBhAGwAaQBiAHIAaQAxAB4A8AAAABEAkAEAAAACAAAHAUMAYQBsAGkAYgByAGkA MQAeAPAAAAAOAJABAAAAAgAABwFDAGEAbABpAGIAcgBpADEAHgDwAAAAPACQAQAAAAIAAAcB QwBhAGwAaQBiAHIAaQAxAB4A8AAAAD4AkAEAAAACAAAHAUMAYQBsAGkAYgByAGkAMQAeAPAA AQA/ALwCAAAAAgAABwFDAGEAbABpAGIAcgBpADEAHgDwAAEANAC8AgAAAAIAAAcBQwBhAGwA aQBiAHIAaQAxAB4A8AAAADQAkAEAAAACAAAHAUMAYQBsAGkAYgByAGkAMQAeAPAAAQAJALwC AAAAAgAABwFDAGEAbABpAGIAcgBpADEAHgDwAAAACgCQAQAAAAIAAAcBQwBhAGwAaQBiAHIA aQAxAB4A8AACABcAkAEAAAACAAAHAUMAYQBsAGkAYgByAGkAMQAeAPAAAQAIALwCAAAAAgAA BwFDAGEAbABpAGIAcgBpADEAHgDwAAAACQCQAQAAAAIAAAcBQwBhAGwAaQBiAHIAaQAeBBwA BQAXAAAiJCIjLCMjMF8pO1woIiQiIywjIzBcKR4EIQAGABwAACIkIiMsIyMwXyk7W1JlZF1c KCIkIiMsIyMwXCkeBCIABwAdAAAiJCIjLCMjMC4wMF8pO1woIiQiIywjIzAuMDBcKR4EJwAI ACIAACIkIiMsIyMwLjAwXyk7W1JlZF1cKCIkIiMsIyMwLjAwXCkeBDcAKgAyAABfKCIkIiog IywjIzBfKTtfKCIkIiogXCgjLCMjMFwpO18oIiQiKiAiLSJfKTtfKEBfKR4ELgApACkAAF8o KiAjLCMjMF8pO18oKiBcKCMsIyMwXCk7XygqICItIl8pO18oQF8pHgQ/ACwAOgAAXygiJCIq ICMsIyMwLjAwXyk7XygiJCIqIFwoIywjIzAuMDBcKTtfKCIkIiogIi0iPz9fKTtfKEBfKR4E NgArADEAAF8oKiAjLCMjMC4wMF8pO18oKiBcKCMsIyMwLjAwXCk7XygqICItIj8/Xyk7XyhA XyngABQAAAAAAPX/IAAAAAAAAAAAAAAAwCDgABQAAQAAAPX/IAAA9AAAAAAAAAAAwCDgABQA AQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAgAAAPX/ IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAA AAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAA wCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQA AAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/ IAAA9AAAAAAAAAAAwCDgABQAAAAAAPX/IAAA9AAAAAAAAAAAwCDgABQAAAAAAAEAIAAAAAAA AAAAAAACwCDgABQABQAAAPX/IAAAtAAAAAAAAAAEiSDgABQABQAAAPX/IAAAtAAAAAAAAAAE ryDgABQABQAAAPX/IAAAtAAAAAAAAAAEnyDgABQABQAAAPX/IAAAtAAAAAAAAAAEiSDgABQA BQAAAPX/IAAAtAAAAAAAAAAEqSDgABQABQAAAPX/IAAAtAAAAAAAAAAEryDgABQABQAAAPX/ IAAAtAAAAAAAAAAErCDgABQABQAAAPX/IAAAtAAAAAAAAAAEryDgABQABQAAAPX/IAAAtAAA AAAAAAAEnyDgABQABQAAAPX/IAAAtAAAAAAAAAAEriDgABQABQAAAPX/IAAAtAAAAAAAAAAE rCDgABQABQAAAPX/IAAAtAAAAAAAAAAEsyDgABQAGQAAAPX/IAAAtAAAAAAAAAAEniDgABQA GQAAAPX/IAAAtAAAAAAAAAAEnSDgABQAGQAAAPX/IAAAtAAAAAAAAAAEnyDgABQAGQAAAPX/ IAAAtAAAAAAAAAAEliDgABQAGQAAAPX/IAAAtAAAAAAAAAAEsSDgABQAGQAAAPX/IAAAtAAA AAAAAAAEryDgABQAGQAAAPX/IAAAtAAAAAAAAAAEviDgABQAGQAAAPX/IAAAtAAAAAAAAAAE kyDgABQAGQAAAPX/IAAAtAAAAAAAAAAEnyDgABQAGQAAAPX/IAAAtAAAAAAAAAAEpCDgABQA GQAAAPX/IAAAtAAAAAAAAAAEsSDgABQAGQAAAPX/IAAAtAAAAAAAAAAEnSDgABQADwAAAPX/ IAAAtAAAAAAAAAAErSDgABQAEwAAAPX/IAAAlBERlwuXCwAEliDgABQAFQAAAPX/IAAAlGZm vx+/HwAEtyDgABQABQArAPX/IAAA+AAAAAAAAAAAwCDgABQABQApAPX/IAAA+AAAAAAAAAAA wCDgABQABQAsAPX/IAAA+AAAAAAAAAAAwCDgABQABQAqAPX/IAAA+AAAAAAAAAAAwCDgABQA FwAAAPX/IAAA9AAAAAAAAAAAwCDgABQADgAAAPX/IAAAtAAAAAAAAAAEqiDgABQACwAAAPX/ IAAA1ABQAAAAHwAAwCDgABQADAAAAPX/IAAA1ABQAAAACwAAwCDgABQADQAAAPX/IAAA1AAg AAAADwAAwCDgABQADQAAAPX/IAAA9AAAAAAAAAAAwCDgABQAEQAAAPX/IAAAlBERlwuXCwAE ryDgABQAFAAAAPX/IAAA1ABgAAAAGgAAwCDgABQAEAAAAPX/IAAAtAAAAAAAAAAEmiDgABQA BQAAAPX/IAAAnBERFgsWCwAEqyDgABQAEgAAAPX/IAAAlBERvx+/HwAEliDgABQABQAJAPX/ IAAA+AAAAAAAAAAAwCDgABQACgAAAPX/IAAA9AAAAAAAAAAAwCDgABQAGAAAAPX/IAAA1ABh AAA+HwAAwCDgABQAFgAAAPX/IAAA9AAAAAAAAAAAwCDgABQABwAAAAEAGQAAGAAAAAAAAAAC wCDgABQABgAAAAEAGQAAGAAAAAAAAAACwCB8CBQAfAgAAAAAAAAAAAAAAABAAE3TKSJ9CC0A fQgAAAAAAAAAAAAAAAAAAAAAAgANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACfQgtAH0IAAAA AAAAAAAAAAAAAQAAAAIADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAn0ILQB9CAAAAAAAAAAA AAAAAAIAAAACAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAAD AAAAAgANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACfQgtAH0IAAAAAAAAAAAAAAAABAAAAAIA DQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAn0ILQB9CAAAAAAAAAAAAAAAAAUAAAACAA0AFAAD AAAAAQAAADAwXCk7XygqDgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAAGAAAAAgANABQAAwAAAAEA AAAwMFwpO18oKg4ABQACfQgtAH0IAAAAAAAAAAAAAAAABwAAAAIADQAUAAMAAAABAAAAMDBc KTtfKCoOAAUAAn0ILQB9CAAAAAAAAAAAAAAAAAgAAAACAA0AFAADAAAAAQAAADAwXCk7Xygq DgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAAJAAAAAgANABQAAwAAAAEAAAAwMFwpO18oKg4ABQAC fQgtAH0IAAAAAAAAAAAAAAAACgAAAAIADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAn0ILQB9 CAAAAAAAAAAAAAAAAAsAAAACAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAJ9CC0AfQgAAAAA AAAAAAAAAAAMAAAAAgANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACfQgtAH0IAAAAAAAAAAAA AAAADQAAAAIADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAn0ILQB9CAAAAAAAAAAAAAAAAA4A AAACAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAJ9CC0AfQgAAAAAAAAAAAAAAAAPAAAAAgAN ABQAAwAAAAEAAAAwMFwpO18oKg4ABQACfQgoAH0IAAAAAAAAAAAAAAAAPgAAAAEADQAUAAMA AAABAAAAMDBcKTtfKCp9CCgAfQgAAAAAAAAAAAAAAAA/AAAAAQANABQAAgAAAAAAAP8wMFwp O18oKn0ILQB9CAAAAAAAAAAAAAAAACsAAAACAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAJ9 CC0AfQgAAAAAAAAAAAAAAAAsAAAAAgANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACfQgtAH0I AAAAAAAAAAAAAAAALQAAAAIADQAUAAMAAAABAAAAMDBcKTtfKCoOAAUAAn0ILQB9CAAAAAAA AAAAAAAAAC4AAAACAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAJ9CC0AfQgAAAAAAAAAAAAA AAA6AAAAAgANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACfQgtAH0IAAAAAAAAAAAAAAAAOwAA AAIADQAUAAMAAAADAAAAMDBcKTtfKCoOAAUAAX0IQQB9CAAAAAAAAAAAAAAAADEAAAADAA0A FAADAAAAAwAAADAwXCk7XygqDgAFAAIIABQAAwAAAAQAAAA7XyhAXykgIH0IQQB9CAAAAAAA AAAAAAAAADIAAAADAA0AFAADAAAAAwAAADAwXCk7XygqDgAFAAIIABQAAwD/PwQAAAA7XyhA XykgIH0IQQB9CAAAAAAAAAAAAAAAADMAAAADAA0AFAADAAAAAwAAADAwXCk7XygqDgAFAAII ABQAAwAyMwQAAAA7XyhAXykgIH0ILQB9CAAAAAAAAAAAAAAAADQAAAACAA0AFAADAAAAAwAA ADAwXCk7XygqDgAFAAJ9CEEAfQgAAAAAAAAAAAAAAAAwAAAAAwANABQAAgAAAABhAP8wMFwp O18oKg4ABQACBAAUAAIAAADG787/O18oQF8pICB9CEEAfQgAAAAAAAAAAAAAAAAoAAAAAwAN ABQAAgAAAJwABv8wMFwpO18oKg4ABQACBAAUAAIAAAD/x87/O18oQF8pICB9CEEAfQgAAAAA AAAAAAAAAAA3AAAAAwANABQAAgAAAJxlAP8wMFwpO18oKg4ABQACBAAUAAIAAAD/65z/O18o QF8pICB9CJEAfQgAAAAAAAAAAAAAAAA1AAAABwANABQAAgAAAD8/dv8wMFwpO18oKg4ABQAC BAAUAAIAAAD/zJn/O18oQF8pICAHABQAAgAAAH9/f/8gICAgICAgIAgAFAACAAAAf39//yAg ICAgICAgCQAUAAIAAAB/f3//AAAAcBPclzQKABQAAgAAAH9/f/8AAADw/1wjNH0IkQB9CAAA AAAAAAAAAAAAADkAAAAHAA0AFAACAAAAPz8//zAwXCk7XygqDgAFAAIEABQAAgAAAPLy8v87 XyhAXykgIAcAFAACAAAAPz8//yAgICAgICAgCAAUAAIAAAA/Pz//ICAgICAgICAJABQAAgAA AD8/P/8AAABwE9yXNAoAFAACAAAAPz8//wAAAPD/XCM0fQiRAH0IAAAAAAAAAAAAAAAAKQAA AAcADQAUAAIAAAD6fQD/MDBcKTtfKCoOAAUAAgQAFAACAAAA8vLy/ztfKEBfKSAgBwAUAAIA AAB/f3//ICAgICAgICAIABQAAgAAAH9/f/8gICAgICAgIAkAFAACAAAAf39//wAAAHAT3Jc0 CgAUAAIAAAB/f3//AAAA8P9cIzR9CEEAfQgAAAAAAAAAAAAAAAA2AAAAAwANABQAAgAAAPp9 AP8wMFwpO18oKg4ABQACCAAUAAIAAAD/gAH/O18oQF8pICB9CJEAfQgAAAAAAAAAAAAAAAAq AAAABwANABQAAwAAAAAAAAAwMFwpO18oKg4ABQACBAAUAAIAAAClpaX/O18oQF8pICAHABQA AgAAAD8/P/8gICAgICAgIAgAFAACAAAAPz8//yAgICAgICAgCQAUAAIAAAA/Pz//AAAAcBPc lzQKABQAAgAAAD8/P/8AAADw/1wjNH0ILQB9CAAAAAAAAAAAAAAAAD0AAAACAA0AFAACAAAA /wAA/zAwXCk7XygqDgAFAAJ9CJEAfQgAAAAAAAAAAAAAAAA4AAAABwANABQAAwAAAAEAAAAw MFwpO18oKg4ABQACBAAUAAIAAAD//8z/O18oQF8pICAHABQAAgAAALKysv8gICAgICAgIAgA FAACAAAAsrKy/yAgICAgICAgCQAUAAIAAACysrL/AAAAcBPclzQKABQAAgAAALKysv8AAADw /1wjNH0ILQB9CAAAAAAAAAAAAAAAAC8AAAACAA0AFAACAAAAf39//zAwXCk7XygqDgAFAAJ9 CFUAfQgAAAAAAAAAAAAAAAA8AAAABAANABQAAwAAAAEAAAAwMFwpO18oKg4ABQACBwAUAAMA AAAEAAAAO18oQF8pICAIABQAAwAAAAQAAAAgICAgICAgIH0IQQB9CAAAAAAAAAAAAAAAACIA AAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAAAAQAAAA7XyhAXykgIH0IQQB9 CAAAAAAAAAAAAAAAABAAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwBlZgQA AAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABYAAAADAA0AFAADAAAAAQAAADAwXCk7Xygq DgAFAAIEABQAAwDMTAQAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABwAAAADAA0AFAAD AAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwQAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAA AAAAACMAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAAAAUAAAA7XyhAXykg IH0IQQB9CAAAAAAAAAAAAAAAABEAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQA AwBlZgUAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABcAAAADAA0AFAADAAAAAQAAADAw XCk7XygqDgAFAAIEABQAAwDMTAUAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAAB0AAAAD AA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwUAAAA7XyhAXykgIH0IQQB9CAAA AAAAAAAAAAAAACQAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAAAAYAAAA7 XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABIAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAF AAIEABQAAwBlZgYAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABgAAAADAA0AFAADAAAA AQAAADAwXCk7XygqDgAFAAIEABQAAwDMTAYAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAA AB4AAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwYAAAA7XyhAXykgIH0I QQB9CAAAAAAAAAAAAAAAACUAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAA AAcAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABMAAAADAA0AFAADAAAAAQAAADAwXCk7 XygqDgAFAAIEABQAAwBlZgcAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABkAAAADAA0A FAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwDMTAcAAAA7XyhAXykgIH0IQQB9CAAAAAAA AAAAAAAAAB8AAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwcAAAA7XyhA XykgIH0IQQB9CAAAAAAAAAAAAAAAACYAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIE ABQAAwAAAAgAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABQAAAADAA0AFAADAAAAAQAA ADAwXCk7XygqDgAFAAIEABQAAwBlZggAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABoA AAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwDMTAgAAAA7XyhAXykgIH0IQQB9 CAAAAAAAAAAAAAAAACAAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQAAwAyMwgA AAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAACcAAAADAA0AFAADAAAAAAAAADAwXCk7Xygq DgAFAAIEABQAAwAAAAkAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAAAAAAABUAAAADAA0AFAAD AAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwBlZgkAAAA7XyhAXykgIH0IQQB9CAAAAAAAAAAA AAAAABsAAAADAA0AFAADAAAAAQAAADAwXCk7XygqDgAFAAIEABQAAwDMTAkAAAA7XyhAXykg IH0IQQB9CAAAAAAAAAAAAAAAACEAAAADAA0AFAADAAAAAAAAADAwXCk7XygqDgAFAAIEABQA AwAyMwkAAAA7XyhAXykgIJMCEgAQAA0AADIwJSAtIEFjY2VudDGSCE0AkggAAAAAAAAAAAAA AQQe/w0AMgAwACUAIAAtACAAQQBjAGMAZQBuAHQAMQAAAAMAAQAMAAcEZWbc5vH/BQAMAAcB AAAAAAD/JQAFAAKTAhIAEQANAAAyMCUgLSBBY2NlbnQykghNAJIIAAAAAAAAAAAAAAEEIv8N ADIAMAAlACAALQAgAEEAYwBjAGUAbgB0ADIAAAADAAEADAAHBWVm8tzb/wUADAAHAQAAAAAA /yUABQACkwISABIADQAAMjAlIC0gQWNjZW50M5IITQCSCAAAAAAAAAAAAAABBCb/DQAyADAA JQAgAC0AIABBAGMAYwBlAG4AdAAzAAAAAwABAAwABwZlZuvx3v8FAAwABwEAAAAAAP8lAAUA ApMCEgATAA0AADIwJSAtIEFjY2VudDSSCE0AkggAAAAAAAAAAAAAAQQq/w0AMgAwACUAIAAt ACAAQQBjAGMAZQBuAHQANAAAAAMAAQAMAAcHZWbk3+z/BQAMAAcBAAAAAAD/JQAFAAKTAhIA FAANAAAyMCUgLSBBY2NlbnQ1kghNAJIIAAAAAAAAAAAAAAEELv8NADIAMAAlACAALQAgAEEA YwBjAGUAbgB0ADUAAAADAAEADAAHCGVm2u7z/wUADAAHAQAAAAAA/yUABQACkwISABUADQAA MjAlIC0gQWNjZW50NpIITQCSCAAAAAAAAAAAAAABBDL/DQAyADAAJQAgAC0AIABBAGMAYwBl AG4AdAA2AAAAAwABAAwABwllZv3p2f8FAAwABwEAAAAAAP8lAAUAApMCEgAWAA0AADQwJSAt IEFjY2VudDGSCE0AkggAAAAAAAAAAAAAAQQf/w0ANAAwACUAIAAtACAAQQBjAGMAZQBuAHQA MQAAAAMAAQAMAAcEzEy4zOT/BQAMAAcBAAAAAAD/JQAFAAKTAhIAFwANAAA0MCUgLSBBY2Nl bnQykghNAJIIAAAAAAAAAAAAAAEEI/8NADQAMAAlACAALQAgAEEAYwBjAGUAbgB0ADIAAAAD AAEADAAHBcxM5ri3/wUADAAHAQAAAAAA/yUABQACkwISABgADQAANDAlIC0gQWNjZW50M5II TQCSCAAAAAAAAAAAAAABBCf/DQA0ADAAJQAgAC0AIABBAGMAYwBlAG4AdAAzAAAAAwABAAwA BwbMTNjkvP8FAAwABwEAAAAAAP8lAAUAApMCEgAZAA0AADQwJSAtIEFjY2VudDSSCE0AkggA AAAAAAAAAAAAAQQr/w0ANAAwACUAIAAtACAAQQBjAGMAZQBuAHQANAAAAAMAAQAMAAcHzEzM wNr/BQAMAAcBAAAAAAD/JQAFAAKTAhIAGgANAAA0MCUgLSBBY2NlbnQ1kghNAJIIAAAAAAAA AAAAAAEEL/8NADQAMAAlACAALQAgAEEAYwBjAGUAbgB0ADUAAAADAAEADAAHCMxMt97o/wUA DAAHAQAAAAAA/yUABQACkwISABsADQAANDAlIC0gQWNjZW50NpIITQCSCAAAAAAAAAAAAAAB BDP/DQA0ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA2AAAAAwABAAwABwnMTPzVtP8FAAwABwEA AAAAAP8lAAUAApMCEgAcAA0AADYwJSAtIEFjY2VudDGSCE0AkggAAAAAAAAAAAAAAQQg/w0A NgAwACUAIAAtACAAQQBjAGMAZQBuAHQAMQAAAAMAAQAMAAcEMjOVs9f/BQAMAAcAAAD///// JQAFAAKTAhIAHQANAAA2MCUgLSBBY2NlbnQykghNAJIIAAAAAAAAAAAAAAEEJP8NADYAMAAl ACAALQAgAEEAYwBjAGUAbgB0ADIAAAADAAEADAAHBTIz2paU/wUADAAHAAAA/////yUABQAC kwISAB4ADQAANjAlIC0gQWNjZW50M5IITQCSCAAAAAAAAAAAAAABBCj/DQA2ADAAJQAgAC0A IABBAGMAYwBlAG4AdAAzAAAAAwABAAwABwYyM8TXm/8FAAwABwAAAP////8lAAUAApMCEgAf AA0AADYwJSAtIEFjY2VudDSSCE0AkggAAAAAAAAAAAAAAQQs/w0ANgAwACUAIAAtACAAQQBj AGMAZQBuAHQANAAAAAMAAQAMAAcHMjOxoMf/BQAMAAcAAAD/////JQAFAAKTAhIAIAANAAA2 MCUgLSBBY2NlbnQ1kghNAJIIAAAAAAAAAAAAAAEEMP8NADYAMAAlACAALQAgAEEAYwBjAGUA bgB0ADUAAAADAAEADAAHCDIzks3c/wUADAAHAAAA/////yUABQACkwISACEADQAANjAlIC0g QWNjZW50NpIITQCSCAAAAAAAAAAAAAABBDT/DQA2ADAAJQAgAC0AIABBAGMAYwBlAG4AdAA2 AAAAAwABAAwABwkyM/q/j/8FAAwABwAAAP////8lAAUAApMCDAAiAAcAAEFjY2VudDGSCEEA kggAAAAAAAAAAAAAAQQd/wcAQQBjAGMAZQBuAHQAMQAAAAMAAQAMAAcEAABPgb3/BQAMAAcA AAD/////JQAFAAKTAgwAIwAHAABBY2NlbnQykghBAJIIAAAAAAAAAAAAAAEEIf8HAEEAYwBj AGUAbgB0ADIAAAADAAEADAAHBQAAwFBN/wUADAAHAAAA/////yUABQACkwIMACQABwAAQWNj ZW50M5IIQQCSCAAAAAAAAAAAAAABBCX/BwBBAGMAYwBlAG4AdAAzAAAAAwABAAwABwYAAJu7 Wf8FAAwABwAAAP////8lAAUAApMCDAAlAAcAAEFjY2VudDSSCEEAkggAAAAAAAAAAAAAAQQp /wcAQQBjAGMAZQBuAHQANAAAAAMAAQAMAAcHAACAZKL/BQAMAAcAAAD/////JQAFAAKTAgwA JgAHAABBY2NlbnQ1kghBAJIIAAAAAAAAAAAAAAEELf8HAEEAYwBjAGUAbgB0ADUAAAADAAEA DAAHCAAAS6zG/wUADAAHAAAA/////yUABQACkwIMACcABwAAQWNjZW50NpIIQQCSCAAAAAAA AAAAAAABBDH/BwBBAGMAYwBlAG4AdAA2AAAAAwABAAwABwkAAPeWRv8FAAwABwAAAP////8l AAUAApMCCAAoAAMAAEJhZJIIOQCSCAAAAAAAAAAAAAABARv/AwBCAGEAZAAAAAMAAQAMAAX/ AAD/x87/BQAMAAX/AACcAAb/JQAFAAKTAhAAKQALAABDYWxjdWxhdGlvbpIIgQCSCAAAAAAA AAAAAAABAhb/CwBDAGEAbABjAHUAbABhAHQAaQBvAG4AAAAHAAEADAAF/wAA8vLy/wUADAAF /wAA+n0A/yUABQACBgAOAAX/AAB/f3//AQAHAA4ABf8AAH9/f/8BAAgADgAF/wAAf39//wEA CQAOAAX/AAB/f3//AQCTAg8AKgAKAABDaGVjayBDZWxskgh/AJIIAAAAAAAAAAAAAAECF/8K AEMAaABlAGMAawAgAEMAZQBsAGwAAAAHAAEADAAF/wAApaWl/wUADAAHAAAA/////yUABQAC BgAOAAX/AAA/Pz//BgAHAA4ABf8AAD8/P/8GAAgADgAF/wAAPz8//wYACQAOAAX/AAA/Pz// BgCTAgQAK4AD/5IIIACSCAAAAAAAAAAAAAABBQP/BQBDAG8AbQBtAGEAAAAAAJMCBAAsgAb/ kggoAJIIAAAAAAAAAAAAAAEFBv8JAEMAbwBtAG0AYQAgAFsAMABdAAAAAACTAgQALYAE/5II JgCSCAAAAAAAAAAAAAABBQT/CABDAHUAcgByAGUAbgBjAHkAAAAAAJMCBAAugAf/kgguAJII AAAAAAAAAAAAAAEFB/8MAEMAdQByAHIAZQBuAGMAeQAgAFsAMABdAAAAAACTAhUALwAQAABF eHBsYW5hdG9yeSBUZXh0kghHAJIIAAAAAAAAAAAAAAECNf8QAEUAeABwAGwAYQBuAGEAdABv AHIAeQAgAFQAZQB4AHQAAAACAAUADAAF/wAAf39//yUABQACkwIJADAABAAAR29vZJIIOwCS CAAAAAAAAAAAAAABARr/BABHAG8AbwBkAAAAAwABAAwABf8AAMbvzv8FAAwABf8AAABhAP8l AAUAApMCDgAxAAkAAEhlYWRpbmcgMZIIRwCSCAAAAAAAAAAAAAABAxD/CQBIAGUAYQBkAGkA bgBnACAAMQAAAAMABQAMAAcDAAAfSX3/JQAFAAIHAA4ABwQAAE+Bvf8FAJMCDgAyAAkAAEhl YWRpbmcgMpIIRwCSCAAAAAAAAAAAAAABAxH/CQBIAGUAYQBkAGkAbgBnACAAMgAAAAMABQAM AAcDAAAfSX3/JQAFAAIHAA4ABwT/P6e/3v8FAJMCDgAzAAkAAEhlYWRpbmcgM5IIRwCSCAAA AAAAAAAAAAABAxL/CQBIAGUAYQBkAGkAbgBnACAAMwAAAAMABQAMAAcDAAAfSX3/JQAFAAIH AA4ABwQyM5Wz1/8CAJMCDgA0AAkAAEhlYWRpbmcgNJIIOQCSCAAAAAAAAAAAAAABAxP/CQBI AGUAYQBkAGkAbgBnACAANAAAAAIABQAMAAcDAAAfSX3/JQAFAAKTAgoANQAFAABJbnB1dJII dQCSCAAAAAAAAAAAAAABAhT/BQBJAG4AcAB1AHQAAAAHAAEADAAF/wAA/8yZ/wUADAAF/wAA Pz92/yUABQACBgAOAAX/AAB/f3//AQAHAA4ABf8AAH9/f/8BAAgADgAF/wAAf39//wEACQAO AAX/AAB/f3//AQCTAhAANgALAABMaW5rZWQgQ2VsbJIISwCSCAAAAAAAAAAAAAABAhj/CwBM AGkAbgBrAGUAZAAgAEMAZQBsAGwAAAADAAUADAAF/wAA+n0A/yUABQACBwAOAAX/AAD/gAH/ BgCTAgwANwAHAABOZXV0cmFskghBAJIIAAAAAAAAAAAAAAEBHP8HAE4AZQB1AHQAcgBhAGwA AAADAAEADAAF/wAA/+uc/wUADAAF/wAAnGUA/yUABQACkwIEAACAAP+SCDMAkggAAAAAAAAA AAAAAQEA/wYATgBvAHIAbQBhAGwAAAACAAUADAAHAQAAAAAA/yUABQACkwIJADgABAAATm90 ZZIIYgCSCAAAAAAAAAAAAAABAgr/BABOAG8AdABlAAAABQABAAwABf8AAP//zP8GAA4ABf8A ALKysv8BAAcADgAF/wAAsrKy/wEACAAOAAX/AACysrL/AQAJAA4ABf8AALKysv8BAJMCCwA5 AAYAAE91dHB1dJIIdwCSCAAAAAAAAAAAAAABAhX/BgBPAHUAdABwAHUAdAAAAAcAAQAMAAX/ AADy8vL/BQAMAAX/AAA/Pz//JQAFAAIGAA4ABf8AAD8/P/8BAAcADgAF/wAAPz8//wEACAAO AAX/AAA/Pz//AQAJAA4ABf8AAD8/P/8BAJMCBAA6gAX/kggkAJIIAAAAAAAAAAAAAAEFBf8H AFAAZQByAGMAZQBuAHQAAAAAAJMCCgA7AAUAAFRpdGxlkggxAJIIAAAAAAAAAAAAAAEDD/8F AFQAaQB0AGwAZQAAAAIABQAMAAcDAAAfSX3/JQAFAAGTAgoAPAAFAABUb3RhbJIITQCSCAAA AAAAAAAAAAABAxn/BQBUAG8AdABhAGwAAAAEAAUADAAHAQAAAAAA/yUABQACBgAOAAcEAABP gb3/AQAHAA4ABwQAAE+Bvf8GAJMCEQA9AAwAAFdhcm5pbmcgVGV4dJIIPwCSCAAAAAAAAAAA AAABAgv/DABXAGEAcgBuAGkAbgBnACAAVABlAHgAdAAAAAIABQAMAAX/AAD/AAD/JQAFAAKO CFgAjggAAAAAAAAAAAAAkAAAABEAEQBUAGEAYgBsAGUAUwB0AHkAbABlAE0AZQBkAGkAdQBt ADkAUABpAHYAbwB0AFMAdAB5AGwAZQBNAGUAZABpAHUAbQA0AJIA4gA4AAAAAAD///8A3QgG AB+3FAAAANQA/PMFAPIIhAAAq+oAkAAAAABkEQAAAJAAkHE6AEYApQAAgIAAwMDAAICAgABj qv4A3S0yAP/1jABO4lcAZxH/AP6nRgCGU1cAor2QAGOq/gDdLTIA//WMAE7iVwBnEf8A/qdG AIZTVwCivZAAAMz/AMz//wDM/8wA//+ZAJnM/wD/mcwAzJn/AP/MmQAzZv8AM8zMAJnMAAD/ zAAA/5kAAP9mAABmZpkAlpaWAAAzZgAzmWYAADMAADMzAACZMwAAmTNmADMzmQAzMzMAXBAO AAMAAAAAAP///wAAAAAAYAECAAAAhQAOAJVLAAAAAAYAU2hlZXQxmggYAJoIAAAAAAAAAAAA AAAAAAAAAAAAAgAAAKMIEACjCAAAAAAAAAAAAAAAAAAAjAAEAAEAAQDBAQgAwQEAAOAiAgDW CBAA1ggAAAAAAAAAAAAAAgAAAPwA9g6LAAAATAAAAAUAAC5BRVJPDAAARG9tYWluIFF1ZXJ5 DQAAQ29udGFjdCBRdWVyeQoAAG5hbWVzZXJ2ZXIJAAByZWdpc3RyYXIHAABERUZBVUxUMAAA dGhlIE5hbWUgZmllbGQgb2YgdGhlIERvbWFpbiBvYmplY3QgaXMgc2VhcmNoZWQuBAAAQVNJ QS8AAFRoZSBpbnB1dCBzdHJpbmcgaXMgc2VhcmNoZWQgaW4gdGhlIE5hbWUgZmllbGQuLQAA VGhlIGlucHV0IHN0cmluZyBpcyBzZWFyY2hlZCBpbiB0aGUgSUQgZmllbGQuTQAAVGhlIGlu cHV0IHN0cmluZyBpcyBzZWFyY2hlZCBpbiB0aGUgbmFtZXNlcnZlciBmaWVsZCBvciB0aGUg SVAgYWRkcmVzcyBmaWVsZC4wAABUaGUgTmFtZSBmaWVsZCBvZiB0aGUgRG9tYWluIG9iamVj dCBpcyBzZWFyY2hlZC4wAACgVGhlIGlucHV0IHN0cmluZyBpcyBzZWFyY2hlZCBpbiB0aGUg TmFtZSBmaWVsZC5UAABodHRwOi8vd3d3LmljYW5uLm9yZy9lbi9hYm91dC9hZ3JlZW1lbnRz L3JlZ2lzdHJpZXMvYXNpYS9hcHBlbmRpeC1zLTA2ZGVjMDYtZW4uaHRtIzZXAABodHRwOi8v d3d3LmljYW5uLm9yZy9lbi9hYm91dC9hZ3JlZW1lbnRzL3JlZ2lzdHJpZXMvYWVyby9hZXJv LWFwcGVuZGl4LTUtMTFqdW4wOS1lbi5odG0DAABCSVpSAABodHRwOi8vd3d3LmljYW5uLm9y Zy9lbi9hYm91dC9hZ3JlZW1lbnRzL3JlZ2lzdHJpZXMvYml6L2FwcGVuZGl4LTA1LTA4ZGVj MDYtZW4uaHRtAwAAQ0FUSAAARWl0aGVyIHRoZSAiRG9tYWluIE5hbWUiLCAiRG9tYWluIE5h bWUgQUNFIiBvciAiRG9tYWluIElEIiBmaWVsZCBpcyB1c2VkRgAARWl0aGVyIHRoZSAiSG9z dCBOYW1lIiwgIkhvc3QgTmFtZSBBQ0UiIG9yIHRoZSAiSG9zdCBJRCIgZmllbGQgaXMgdXNl ZDQAAFNlYXJjaCBmb3IgY29udGFjdCBvYmplY3RzIGluIHRoZSAiQ29udGFjdCBJRCIgZmll bGRUAABTZWFyY2ggZm9yIHJlZ2lzdHJhciBvYmplY3RzIGluIHRoZSAiUmVnaXN0cmFyIElE IiBvciAiUmVnaXN0cmFyIE9yZ2FuaXphdGlvbiIgZmllbGRUAABodHRwOi8vd3d3LmljYW5u Lm9yZy9lbi9hYm91dC9hZ3JlZW1lbnRzL3JlZ2lzdHJpZXMvY2F0L2NhdC1hcHBlbmRpeHMt MjJtYXIwNi1lbi5odG1bAACgdGhlIGVudHJ5IHBhcmFtZXRlciBpcyB0aGUgZnVsbCBuYW1l IG9mIHRoZSByZWdpc3RyYXIgKGluY2x1ZGluZyBwdW5jdHVhdGlvbiwgIkluYy4iLCBldGMu OwAAdGhlIGVudHJ5IHBhcmFtZXRlciBpcyB0aGUgZG9tYWluIG5hbWUgKGluY2x1ZGluZyB0 aGUgVExEKTpJAAB3aGVyZSB0aGUgZW50cnkgcGFyYW1ldGVyIGlzIGVpdGhlciB0aGUgZnVs bCBob3N0IG5hbWUgb3IgdGhlIElQIGFkZHJlc3M6DQAATm90IEF2YWlsYWJsZVcAAGh0dHA6 Ly93d3cuaWNhbm4ub3JnL2VuL2Fib3V0L2FncmVlbWVudHMvcmVnaXN0cmllcy92ZXJpc2ln bi9hcHBlbmRpeC0wNS0wMW1hcjA2LWVuLmh0bQQAAENPT1BUAACgVGhlIGlucHV0IHN0cmlu ZyBpcyBzZWFyY2hlZCBpbiB0aGUgbmFtZXNlcnZlciBuYW1lIGZpZWxkIGFuZCB0aGUgSVAg YWRkcmVzcyBmaWVsZC5YAABodHRwOi8vd3d3LmljYW5uLm9yZy9lbi9hYm91dC9hZ3JlZW1l bnRzL3JlZ2lzdHJpZXMvY29vcC9hcHBlbmRpeC1zLTAxanVsMDctZW4uaHRtI3BhcnQ1BAAA SU5GT0gAAFRoZSBpbnB1dCBzdHJpbmcgaXMgc2VhcmNoZWQgaW4gdGhlIE5hbWUgZmllbGQg YW5kIHRoZSBJUCBBZGRyZXNzIGZpZWxkLlMAAGh0dHA6Ly93d3cuaWNhbm4ub3JnL2VuL2Fi b3V0L2FncmVlbWVudHMvcmVnaXN0cmllcy9pbmZvL2FwcGVuZGl4LTA1LTA4ZGVjMDYtZW4u aHRtBAAASk9CU1gAAGh0dHA6Ly93d3cuaWNhbm4ub3JnL2VuL2Fib3V0L2FncmVlbWVudHMv cmVnaXN0cmllcy9qb2JzL2FwcGVuZGl4LXMtMDZhdWcxMC1lbi5odG0jUGFydDYEAABNT0JJ VgAAaHR0cDovL3d3dy5pY2Fubi5vcmcvZW4vYWJvdXQvYWdyZWVtZW50cy9yZWdpc3RyaWVz L21vYmkvbW9iaS1hcHBlbmRpeHMtMjNub3YwNS1lbi5odG0GAABNVVNFVU1VAABodHRwOi8v d3d3LmljYW5uLm9yZy9lbi9hYm91dC9hZ3JlZW1lbnRzL3JlZ2lzdHJpZXMvbXVzZXVtL2Fw cGVuZGl4LTA1LTAzbm92MDctZW4uaHRtBAAATkFNRRUAAFZlcnkgaW50ZXJlc3RpbmcgY2Fz ZTYAAFRoZSBpbnB1dCBzdHJpbmcgaXMgc2VhcmNoZWQgaW4gdGhlIERvbWFpbiBOYW1lIGZp ZWxkLiEAAFNlYXJjaCBvbmx5IG9uIGNvbnRhY3Qgb2JqZWN0IElELk4AAKBUaGUgaW5wdXQg c3RyaW5nIGlzIHNlYXJjaGVkIGluIHRoZSBOYW1lIGZpZWxkIGFuZCBpbiB0aGUgcmVnaXN0 cmFyIElEIGZpZWxkLlMAAGh0dHA6Ly93d3cuaWNhbm4ub3JnL2VuL2Fib3V0L2FncmVlbWVu dHMvcmVnaXN0cmllcy9uYW1lL2FwcGVuZGl4LTA1LTE1YXVnMDctZW4uaHRtAwAATkVUAwAA T1JHMQAAoHRoZSBOYW1lIGZpZWxkIG9mIHRoZSBEb21haW4gb2JqZWN0IGlzIHNlYXJjaGVk LlIAAGh0dHA6Ly93d3cuaWNhbm4ub3JnL2VuL2Fib3V0L2FncmVlbWVudHMvcmVnaXN0cmll cy9vcmcvYXBwZW5kaXgtMDUtMDhkZWMwNi1lbi5odG1RAABodHRwOi8vd3d3LmljYW5uLm9y Zy9lbi9hYm91dC9hZ3JlZW1lbnRzL3JlZ2lzdHJpZXMvbmV0L2FwcGVuZGl4LTUtMDFqdWwx MS1lbi5odG0EAABQT1NUVwAAaHR0cDovL3d3dy5pY2Fubi5vcmcvZW4vYWJvdXQvYWdyZWVt ZW50cy9yZWdpc3RyaWVzL3Bvc3QvcG9zdC1hcHBlbmRpeC1zLTExZGVjMDktZW4uaHRtAwAA UFJPVQAAaHR0cDovL3d3dy5pY2Fubi5vcmcvZW4vYWJvdXQvYWdyZWVtZW50cy9yZWdpc3Ry aWVzL3Byby9wcm8tYXBwZW5kaXgtNS0yMmFwcjEwLWVuLmh0bQMAAFRFTCYAAKBPbmx5IHRo ZSAiRG9tYWluIE5hbWUiIGZpZWxkIGlzIHVzZWSgNQABUwBlAGEAcgBjAGgAIABmAG8AcgAg AGMAbwBuAHQAYQBjAHQAIABvAGIAagBlAGMAdABzACAAaQBuACAAdABoAGUAIAAcIEMAbwBu AHQAYQBjAHQAIABJAEQAHSAgAGYAaQBlAGwAZACgAHQAAVMAZQBhAHIAYwBoACAAbwBuAGwA eQAgAGIAeQAgAG4AYQBtAGUAIABzAGUAcgB2AGUAcgAgAG8AYgBqAGUAYwB0AHMALgAgAFQA aABlACAAaQBuAHAAdQB0ACAAcwB0AHIAaQBuAGcAIABpAHMAIABtAGEAdABjAGgAZQBkACAA YQBnAGEAaQBuAHMAdAAgABwgSABvAHMAdAAgAE4AYQBtAGUAHSAgAG8AcgAgAHQAaABlACAA HCBIAG8AcwB0ACAASQBEAB0gIABmAGkAZQBsAGQAIABjAG8AbgB0AGUAbgB0AHMAoABVAABT ZWFyY2ggZm9yIHJlZ2lzdHJhciBvYmplY3RzIGluIHRoZSAiUmVnaXN0cmFyIElEIiBvciAi UmVnaXN0cmFyIE9yZ2FuaXphdGlvbiIgZmllbGSgVwAAaHR0cDovL3d3dy5pY2Fubi5vcmcv ZW4vYWJvdXQvYWdyZWVtZW50cy9yZWdpc3RyaWVzL3RlbC9hcHBlbmRpeC1zLTAyZmViMTEt ZW4uaHRtI1BhcnQ2BgAAVFJBVkVMYQAAaHR0cDovL3d3dy5pY2Fubi5vcmcvZW4vYWJvdXQv YWdyZWVtZW50cy9yZWdpc3RyaWVzL3RyYXZlbC90cmF2ZWwtYXBwZW5kaXgtcy0xMmFwcjA2 LWVuLmh0bSNwYXJ0NgMAAFhYWFEAAGh0dHA6Ly93d3cuaWNhbm4ub3JnL2VuL2Fib3V0L2Fn cmVlbWVudHMvcmVnaXN0cmllcy94eHgvYXBwZW5kaXgtcy0zMW1hcjExLWVuLmh0bQkAAG5l dyBnVExEcwsAAGRvbWFpbiBuYW1lCgAAY29udGFjdCBJRA4AAHJlZ2lzdHJhciBuYW1lSQAA aHR0cDovL25ld2d0bGRzLmljYW5uLm9yZy9lbi9hcHBsaWNhbnRzL2FnYi9ndWlkZWJvb2st ZnVsbC0xMWphbjEyLWVuLnBkZikAAENPTSAoYm90aCBleGlzdGluZyBhbmQgcHJvcG9zZWQg cmVuZXdhbHMpGAAAbmFtZXNlcnZlciBvciBpcCBhZGRyZXNzIwAAdmVyeSBpbnRlcmVzdGlu ZyBjYXNlIGFib3V0IHByaXZhY3kgAABjb250YWlucyB2ZXJ5IGdvb2QgZG9jdW1lbnRhdGlv bgUAAE5PVEVTBwAAU291cmNlOv8AUgAIALMvAAAMAAAANzAAAJAAAAAGMgAAXwIAADg0AACR BAAA7DUAAEUGAACwNwAACQgAAN84AAA4CQAAgToAANoKAAAnPQAAgA0AAEY+AACfDgAAlgiW DJYIAAAAAAAAAAAAAAAAAABQSwMEFAAGAAgAAAAhAJvocE/8AAAAHAIAABMAAABbQ29udGVu dF9UeXBlc10ueG1srJHLasMwEEX3hf6D0LbYcroopdjOoo9dH4v0AwZ5bIvYIyFNQvL3HTsu lBIChW4E0sy998yoXB/GQe0xJuep0qu80ArJ+sZRV+nPzUt2r1VioAYGT1jpIya9rq+vys0x YFKiplTpnjk8GJNsjyOk3AckqbQ+jsByjZ0JYLfQobktijtjPTESZzx56Lp8whZ2A6vngzyf SESu1eOpb4qqNIQwOAssoGaqmrO6iEO6INxT84suW8hyUc7mqXch3SwJ77Ka6BpUHxD5DUbh MCxD4s/zFUhGi/ll5jPRvm2dxcbb3SjryGfjxexPAKv/if7ONPPf1l8AAAD//wMAUEsDBBQA BgAIAAAAIQCl1qfnwAAAADYBAAALAAAAX3JlbHMvLnJlbHOEj89qwzAMh++FvYPRfVHSwxgl di+lkEMvo30A4Sh/aCIb2xvr20/HBgq7CISk7/epPf6ui/nhlOcgFpqqBsPiQz/LaOF2Pb9/ gsmFpKclCFt4cIaje9u1X7xQ0aM8zTEbpUi2MJUSD4jZT7xSrkJk0ckQ0kpF2zRiJH+nkXFf 1x+YnhngNkzT9RZS1zdgro+oyf+zwzDMnk/Bf68s5UUEbjeUTGnkYqGoL+NTvZCoZarUHtC1 uPnW/QEAAP//AwBQSwMEFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAB0aGVtZS90aGVtZS90 aGVtZU1hbmFnZXIueG1sDMxNCsMgEEDhfaF3kNk3Y7soRWKyy6679gBDnBpBx6DSn9vX5eOD N87fFNWbSw1ZLJwHDYplzS6It/B8LKcbqNpIHMUsbOHHFebpeBjJtI0T30nIc1F9I9WQha21 3SDWtSvVIe8s3V65JGo9i0dX6NP3KeJF6ysmCgI4/QEAAP//AwBQSwMEFAAGAAgAAAAhADAP iGsRBwAA3h0AABYAAAB0aGVtZS90aGVtZS90aGVtZTEueG1s7FlPbxtFFL8j8R1Ge29jJ3Ya R3Wq2LFbaNNGsVvU43g99k4zu7OaGSfxDbVHJCREQVyQuHFAQKVW4lI+TaAIitSvwJuZ3fVO PG6cEkBAc2i9s7/35r3f+zN/9uq145ihQyIk5UkzqF6uBIgkIR/SZNwM7va7lzYCJBVOhpjx hDSDKZHBta1337mKN1VEYoJAPpGbuBlESqWbKysyhGEsL/OUJPBuxEWMFTyK8cpQ4CPQG7OV 1UplfSXGNAlQgmNQe2c0oiFBfa0y2MqVdxg8JkrqgZCJnlZNHAmDHR5UNUJOZZsJdIhZM4B5 hvyoT45VgBiWCl40g4r5C1a2rq7gzUyIqQWyJbmu+cvkMoHhwaqZU4wHxaTVbq1xZafQbwBM zeM6nU67Uy30GQAOQ/DU2lLWWetuVFu5zhLI/pzX3a7UKzUXX9K/Nmdzo9Vq1RuZLVapAdmf tTn8RmW9tr3q4A3I4utz+Fpru91ed/AGZPHrc/julcZ6zcUbUMRocjCH1gHtdjPtBWTE2Q0v fAPgG5UMPkNBNhTZpacY8UQtyrUYP+CiCwANZFjRBKlpSkY4hCxu43ggKNYT4E2CS2/sUCjn hvRcSIaCpqoZvJ9iqIiZvlfPv331/Cl69fzJycNnJw9/OHn06OTh91aXI3gDJ+Oy4MuvP/n9 yw/Rb0+/evn4Mz9elvE/f/fRTz9+6gdCBc0sevH5k1+ePXnxxce/fvPYA98WeFCG92lMJLpN jtA+j8E3Q4xrORmI80n0I0wdCRyBbo/qjooc4O0pZj5ci7jk3RPQPHzA65MHjq29SEwU9cx8 M4od4C7nrMWFl4Cbeq4Sw/1JMvZPLiZl3D7Gh7652zhxQtuZpNA186R0uG9HxDFzj+FE4TFJ iEL6HT8gxOPdfUodXndpKLjkI4XuU9TC1EtJnw6cRJoJ3aAxxGXq8xlC7XCzew+1OPN5vUMO XSQUBGYe4/uEOTRexxOFY5/KPo5ZmfBbWEU+I3tTEZZxHakg0mPCOOoMiZQ+mTsC/C0F/SaG fuUN+y6bxi5SKHrg03kLc15G7vCDdoTj1Ift0SQqY9+TB5CiGO1x5YPvcrdC9DPEAScLw32P EifcZzeCu3TsmDRLEP1mIjyxvE64k7+9KRthYroMtHSnU8c0eV3bZhT6tp3hbdtuBtuwiPmK 58apZr0I9y9s0Tt4kuwRqIr5Jepth37boYP/fIdeVMsX35dnrRi6tN6Q2L222XnHCzfeI8pY T00ZuSXN3lvCAjTswqCWM4dOUhzE0gh+6kqGCRzcWGAjgwRXH1AV9SKcwr69GmglY5mpHkuU cgnnRTPs1a3xsPdX9rRZ1+cQ2zkkVrt8aIfX9HB+3CjUGKvG5kybT7SmFSw72dqVTCn49iaT VbVRS89WNaaZpujMVrisKTbncqC8cA0GCzZhZ4NgPwQsr8OxX08N5x3MyFDzbmOUh8VE4a8J Uea1dSTCQ2JD5AyX2Kya2OUpNOefds/myPnYLFgD0s42wqTF4vxZkuRcwYxkEDxdTSwp1xZL 0FEzaNRX6wEKcdoMRnDShZ9xCkGTei+I2Riui0IlbNaeWYumSGceN/xZVYXLiwUF45RxKqTa wTKyMTSvslCxRM9k7V+t13SyXYwDnmaynBVrG5Ai/5gVEGo3tGQ0IqEqB7s0ormzj1kn5BNF RC8aHqEBm4h9DOEHTrU/QyrhwsIUtH6A2zXNtnnl9tas05TvtAzOjmOWRjjrlvp2Jq84Czf9 pLDBPJXMA9+8thvnzu+KrviLcqWcxv8zV/RyADcIa0MdgRAudwVGulKaARcq4tCF0oiGXQHr vukdkC1wQwuvgXy4Yjb/C3Ko/7c1Z3WYsoaDoNqnYyQoLCcqEoTsQVsy2XeGsmq29FiVLFNk Mqpkrkyt2QNySFhf98B13YMDFEGqm26StQGDO51/7nNWQYOx3qOU683pZMXSaWvg79642GIG p07tJXT+5vwXJhar+2z1s/JGPF8jy47oF7NdUi2vCmfxazSyqd7QhGUW4NJaazvWnMer9dw4 iOK8xzBY7GdSuAdC+h9Y/6gImf1eoRfUPt+H3org84PlD0FWX9JdDTJIN0j7awD7Hjtok0mr stRmOx/NWr5YX/BGtZj3FNnasmXifU6yi02UO51TixdJdsaww7UdW0g1RPZ0icLQKD+HmMCY D13lb1F88AACvQO3/hNmv07JFJ5MHaR7wmTXgA+n2U8m7YJrs06fYTSSJftkhOjwOD9/FEzY ErJfSPItskFrMZ1oheCa79DgCmZ4LWpXy0J49WzhQsLMDC27EDYXaj4F8H0sa9z6aAd422St 17q4cqZY8mcoW8J4P2Xek8+ylNmD4msD9QaUqePXU5YxBeTNJx584RQYjl49039h0bGZblJ2 6w8AAAD//wMAUEsDBBQABgAIAAAAIQAN0ZCftgAAABsBAAAnAAAAdGhlbWUvdGhlbWUvX3Jl bHMvdGhlbWVNYW5hZ2VyLnhtbC5yZWxzhI9NCsIwFIT3gncIb2/TuhCRJt2I0K3UA4TkNQ02 PyRR7O0NriwILodhvplpu5edyRNjMt4xaKoaCDrplXGawW247I5AUhZOidk7ZLBggo5vN+0V Z5FLKE0mJFIoLjGYcg4nSpOc0IpU+YCuOKOPVuQio6ZByLvQSPd1faDxmwF8xSS9YhB71QAZ llCa/7P9OBqJZy8fFl3+UUFz2YUFKKLGzOAjm6pMBMpburrE3wAAAP//AwBQSwECLQAUAAYA CAAAACEAm+hwT/wAAAAcAgAAEwAAAAAAAAAAAAAAAAAAAAAAW0NvbnRlbnRfVHlwZXNdLnht bFBLAQItABQABgAIAAAAIQCl1qfnwAAAADYBAAALAAAAAAAAAAAAAAAAAC0BAABfcmVscy8u cmVsc1BLAQItABQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAAAAAAAAAAAAAABYCAAB0aGVt ZS90aGVtZS90aGVtZU1hbmFnZXIueG1sUEsBAi0AFAAGAAgAAAAhADAPiGsRBwAA3h0AABYA AAAAAAAAAAAAAAAA0wIAAHRoZW1lL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEA DdGQn7YAAAAbAQAAJwAAAAAAAAAAAAAAAAAYCgAAdGhlbWUvdGhlbWUvX3JlbHMvdGhlbWVN YW5hZ2VyLnhtbC5yZWxzUEsFBgAAAAAFAAUAXQEAABMLAAAAAAoAAAAJCBAAAAYQANlUzAcA AAMABgYAAAsCFAAAAAAAAwAAABEAAAAzaAAAB3EAAA0AAgABAAwAAgBkAA8AAgABABEAAgAA ABAACAD8qfHSTWJQP18AAgABACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAA AFQBgQACAMEEFAAAABUAAACDAAIAAACEAAIAAABNAGAbAxA8P3htbCB2ZXJzaW9uPSIxLjAi IGVuY29kaW5nPSJVVEYtOCI/Pgo8IURPQ1RZUEUgcGxpc3QgUFVCTElDICItLy9BcHBsZS8v RFREIFBMSVNUIDEuMC8vRU4iICJodHRwOi8vd3d3LmFwcGxlLmNvbS9EVERzL1Byb3BlcnR5 TGlzdC0xLjAuZHRkIj4KPHBsaXN0IHZlcnNpb249IjEuMCI+CjxkaWN0PgoJPGtleT5jb20u YXBwbGUucHJpbnQuUGFnZUZvcm1hdC5Gb3JtYXR0aW5nUHJpbnRlcjwva2V5PgoJPGRpY3Q+ CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQk8c3RyaW5n PmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50 aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJCTxrZXk+Y29t LmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuRm9ybWF0dGluZ1ByaW50ZXI8L2tleT4KCQkJCTxz dHJpbmc+IDwvc3RyaW5nPgoJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRl RmxhZzwva2V5PgoJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJPC9kaWN0PgoJCTwvYXJy YXk+Cgk8L2RpY3Q+Cgk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNSG9yaXpv bnRhbFJlczwva2V5PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNy ZWF0b3I8L2tleT4KCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4KCQk8 a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJPGFycmF5PgoJ CQk8ZGljdD4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1Ib3Jpem9u dGFsUmVzPC9rZXk+CgkJCQk8cmVhbD4zMDA8L3JlYWw+CgkJCQk8a2V5PmNvbS5hcHBsZS5w cmludC50aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJ CQk8L2RpY3Q+CgkJPC9hcnJheT4KCTwvZGljdD4KCTxrZXk+Y29tLmFwcGxlLnByaW50LlBh Z2VGb3JtYXQuUE1PcmllbnRhdGlvbjwva2V5PgoJPGRpY3Q+CgkJPGtleT5jb20uYXBwbGUu cHJpbnQudGlja2V0LmNyZWF0b3I8L2tleT4KCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNr ZXQ8L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9r ZXk+CgkJPGFycmF5PgoJCQk8ZGljdD4KCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VG b3JtYXQuUE1PcmllbnRhdGlvbjwva2V5PgoJCQkJPGludGVnZXI+MTwvaW50ZWdlcj4KCQkJ CTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCTxpbnRl Z2VyPjA8L2ludGVnZXI+CgkJCTwvZGljdD4KCQk8L2FycmF5PgoJPC9kaWN0PgoJPGtleT5j b20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTVNjYWxpbmc8L2tleT4KCTxkaWN0PgoJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJPHN0cmluZz5jb20u YXBwbGUuam9idGlja2V0PC9zdHJpbmc+CgkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0 Lml0ZW1BcnJheTwva2V5PgoJCTxhcnJheT4KCQkJPGRpY3Q+CgkJCQk8a2V5PmNvbS5hcHBs ZS5wcmludC5QYWdlRm9ybWF0LlBNU2NhbGluZzwva2V5PgoJCQkJPHJlYWw+MTwvcmVhbD4K CQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCTxp bnRlZ2VyPjA8L2ludGVnZXI+CgkJCTwvZGljdD4KCQk8L2FycmF5PgoJPC9kaWN0PgoJPGtl eT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTVZlcnRpY2FsUmVzPC9rZXk+Cgk8ZGlj dD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5PgoJCTxzdHJp bmc+Y29tLmFwcGxlLmpvYnRpY2tldDwvc3RyaW5nPgoJCTxrZXk+Y29tLmFwcGxlLnByaW50 LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQk8YXJyYXk+CgkJCTxkaWN0PgoJCQkJPGtleT5j b20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTVZlcnRpY2FsUmVzPC9rZXk+CgkJCQk8cmVh bD4zMDA8L3JlYWw+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFn PC9rZXk+CgkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQk8L2RpY3Q+CgkJPC9hcnJheT4K CTwvZGljdD4KCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1WZXJ0aWNhbFNj YWxpbmc8L2tleT4KCTxkaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVh dG9yPC9rZXk+CgkJPHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0PC9zdHJpbmc+CgkJPGtl eT5jb20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCTxhcnJheT4KCQkJ PGRpY3Q+CgkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0LlBNVmVydGljYWxT Y2FsaW5nPC9rZXk+CgkJCQk8cmVhbD4xPC9yZWFsPgoJCQkJPGtleT5jb20uYXBwbGUucHJp bnQudGlja2V0LnN0YXRlRmxhZzwva2V5PgoJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJ PC9kaWN0PgoJCTwvYXJyYXk+Cgk8L2RpY3Q+Cgk8a2V5PmNvbS5hcHBsZS5wcmludC5zdWJU aWNrZXQucGFwZXJfaW5mb190aWNrZXQ8L2tleT4KCTxkaWN0PgoJCTxrZXk+UE1QUERQYXBl ckNvZGVOYW1lPC9rZXk+CgkJPGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tl dC5jcmVhdG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRpY2tldDwvc3RyaW5n PgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJCTxh cnJheT4KCQkJCTxkaWN0PgoJCQkJCTxrZXk+UE1QUERQYXBlckNvZGVOYW1lPC9rZXk+CgkJ CQkJPHN0cmluZz5MZXR0ZXI8L3N0cmluZz4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50 aWNrZXQuc3RhdGVGbGFnPC9rZXk+CgkJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJCTwv ZGljdD4KCQkJPC9hcnJheT4KCQk8L2RpY3Q+CgkJPGtleT5QTVRpb2dhUGFwZXJOYW1lPC9r ZXk+CgkJPGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9r ZXk+CgkJCTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRpY2tldDwvc3RyaW5nPgoJCQk8a2V5PmNv bS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJCTxhcnJheT4KCQkJCTxk aWN0PgoJCQkJCTxrZXk+UE1UaW9nYVBhcGVyTmFtZTwva2V5PgoJCQkJCTxzdHJpbmc+bmEt bGV0dGVyPC9zdHJpbmc+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0YXRl RmxhZzwva2V5PgoJCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCQk8L2RpY3Q+CgkJCTwv YXJyYXk+CgkJPC9kaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3JtYXQuUE1B ZGp1c3RlZFBhZ2VSZWN0PC9rZXk+CgkJPGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50 LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRpY2tldDwv c3RyaW5nPgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+ CgkJCTxhcnJheT4KCQkJCTxkaWN0PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VG b3JtYXQuUE1BZGp1c3RlZFBhZ2VSZWN0PC9rZXk+CgkJCQkJPGFycmF5PgoJCQkJCQk8aW50 ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJCQk8cmVh bD4zMDU4LjMzMzMzMzMzMzMzMzU8L3JlYWw+CgkJCQkJCTxyZWFsPjI0MDA8L3JlYWw+CgkJ CQkJPC9hcnJheT4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuc3RhdGVGbGFn PC9rZXk+CgkJCQkJPGludGVnZXI+MDwvaW50ZWdlcj4KCQkJCTwvZGljdD4KCQkJPC9hcnJh eT4KCQk8L2RpY3Q+CgkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFnZUZvcm1hdC5QTUFkanVz dGVkUGFwZXJSZWN0PC9rZXk+CgkJPGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRp Y2tldC5jcmVhdG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRpY2tldDwvc3Ry aW5nPgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJ CTxhcnJheT4KCQkJCTxkaWN0PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhZ2VGb3Jt YXQuUE1BZGp1c3RlZFBhcGVyUmVjdDwva2V5PgoJCQkJCTxhcnJheT4KCQkJCQkJPHJlYWw+ LTc1PC9yZWFsPgoJCQkJCQk8cmVhbD4tNzU8L3JlYWw+CgkJCQkJCTxyZWFsPjMyMjUuMDAw MDAwMDAwMDAwNTwvcmVhbD4KCQkJCQkJPHJlYWw+MjQ3NTwvcmVhbD4KCQkJCQk8L2FycmF5 PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJ CQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGlj dD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1DdXN0b21QYXBlcjwva2V5 PgoJCTxkaWN0PgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuY3JlYXRvcjwva2V5 PgoJCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmluZz4KCQkJPGtleT5jb20u YXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCQk8YXJyYXk+CgkJCQk8ZGlj dD4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1DdXN0b21QYXBlcjwv a2V5PgoJCQkJCTxmYWxzZS8+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LnN0 YXRlRmxhZzwva2V5PgoJCQkJCTxpbnRlZ2VyPjA8L2ludGVnZXI+CgkJCQk8L2RpY3Q+CgkJ CTwvYXJyYXk+CgkJPC9kaWN0PgoJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhcGVySW5mby5Q TVBhcGVyTmFtZTwva2V5PgoJCTxkaWN0PgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNr ZXQuY3JlYXRvcjwva2V5PgoJCQk8c3RyaW5nPmNvbS5hcHBsZS5qb2J0aWNrZXQ8L3N0cmlu Zz4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0Lml0ZW1BcnJheTwva2V5PgoJCQk8 YXJyYXk+CgkJCQk8ZGljdD4KCQkJCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8u UE1QYXBlck5hbWU8L2tleT4KCQkJCQk8c3RyaW5nPm5hLWxldHRlcjwvc3RyaW5nPgoJCQkJ CTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50 ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8 a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8uUE1VbmFkanVzdGVkUGFnZVJlY3Q8L2tl eT4KCQk8ZGljdD4KCQkJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LmNyZWF0b3I8L2tl eT4KCQkJPHN0cmluZz5jb20uYXBwbGUuam9idGlja2V0PC9zdHJpbmc+CgkJCTxrZXk+Y29t LmFwcGxlLnByaW50LnRpY2tldC5pdGVtQXJyYXk8L2tleT4KCQkJPGFycmF5PgoJCQkJPGRp Y3Q+CgkJCQkJPGtleT5jb20uYXBwbGUucHJpbnQuUGFwZXJJbmZvLlBNVW5hZGp1c3RlZFBh Z2VSZWN0PC9rZXk+CgkJCQkJPGFycmF5PgoJCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJ CQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJCQk8cmVhbD43MzQ8L3JlYWw+CgkJCQkJ CTxyZWFsPjU3NjwvcmVhbD4KCQkJCQk8L2FycmF5PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnBy aW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJ CQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmlu dC5QYXBlckluZm8uUE1VbmFkanVzdGVkUGFwZXJSZWN0PC9rZXk+CgkJPGRpY3Q+CgkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVhdG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29t LmFwcGxlLmpvYnRpY2tldDwvc3RyaW5nPgoJCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNr ZXQuaXRlbUFycmF5PC9rZXk+CgkJCTxhcnJheT4KCQkJCTxkaWN0PgoJCQkJCTxrZXk+Y29t LmFwcGxlLnByaW50LlBhcGVySW5mby5QTVVuYWRqdXN0ZWRQYXBlclJlY3Q8L2tleT4KCQkJ CQk8YXJyYXk+CgkJCQkJCTxyZWFsPi0xODwvcmVhbD4KCQkJCQkJPHJlYWw+LTE4PC9yZWFs PgoJCQkJCQk8cmVhbD43NzQ8L3JlYWw+CgkJCQkJCTxyZWFsPjU5NDwvcmVhbD4KCQkJCQk8 L2FycmF5PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tl eT4KCQkJCQk8aW50ZWdlcj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJ CTwvZGljdD4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC5QYXBlckluZm8ucHBkLlBNUGFwZXJO YW1lPC9rZXk+CgkJPGRpY3Q+CgkJCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5jcmVh dG9yPC9rZXk+CgkJCTxzdHJpbmc+Y29tLmFwcGxlLmpvYnRpY2tldDwvc3RyaW5nPgoJCQk8 a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQuaXRlbUFycmF5PC9rZXk+CgkJCTxhcnJheT4K CQkJCTxkaWN0PgoJCQkJCTxrZXk+Y29tLmFwcGxlLnByaW50LlBhcGVySW5mby5wcGQuUE1Q YXBlck5hbWU8L2tleT4KCQkJCQk8c3RyaW5nPlVTIExldHRlcjwvc3RyaW5nPgoJCQkJCTxr ZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC5zdGF0ZUZsYWc8L2tleT4KCQkJCQk8aW50ZWdl cj4wPC9pbnRlZ2VyPgoJCQkJPC9kaWN0PgoJCQk8L2FycmF5PgoJCTwvZGljdD4KCQk8a2V5 PmNvbS5hcHBsZS5wcmludC50aWNrZXQuQVBJVmVyc2lvbjwva2V5PgoJCTxzdHJpbmc+MDAu MjA8L3N0cmluZz4KCQk8a2V5PmNvbS5hcHBsZS5wcmludC50aWNrZXQudHlwZTwva2V5PgoJ CTxzdHJpbmc+Y29tLmFwcGxlLnByaW50LlBhcGVySW5mb1RpY2tldDwvc3RyaW5nPgoJPC9k aWN0PgoJPGtleT5jb20uYXBwbGUucHJpbnQudGlja2V0LkFQSVZlcnNpb248L2tleT4KCTxz dHJpbmc+MDAuMjA8L3N0cmluZz4KCTxrZXk+Y29tLmFwcGxlLnByaW50LnRpY2tldC50eXBl PC9rZXk+Cgk8c3RyaW5nPmNvbS5hcHBsZS5wcmludC5QYWdlRm9ybWF0VGlja2V0PC9zdHJp bmc+CjwvZGljdD4KPC9wbGlzdD4KTQB6AAEAAAMAAAEsASwAAAAAC/MJYP+1/7UMmgmrA2cF KAP8AAIAAABIAEgAAAAAAtgCKAABAAAAZAAAAAEAAwMDAAAAAX//AAEAAQAAAAAAAAAAAAAA AGgIABkBkAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoQAiAAEAZAABAAEAAQAC APz//P8AAAAAAADgPwAAAAAAAOA/AQBVAAIACgB9AAwAAAAAAdUZPgAAAAIAAAIOAAMAAAAR AAAAAAAUAAAACAIQAAMAAAAUAKgCAAAAAAABDwAIAhAABAAAABQApAYAAAAAAAEPAAgCEAAF AAAAFACoAgAAAAAAAQ8ACAIQAAYAAAAUAFAFAAAAAAABDwAIAhAABwAAABQA/AMAAAAAAAEP AAgCEAAIAAAAFAD4BwAAAAAAAQ8ACAIQAAkAAAAUAFAFAAAAAAABDwAIAhAACgAAABQA/AMA AAAAAAEPAAgCEAALAAAAFABUAQAAAAAAAQ8ACAIQAA0AAAAUAFQBAAAAAAABDwAIAhAAEAAI AAkAVAEAAAAAAAEPAP0ACgADAAEAPgBBAAAA/QAKAAMAAgA+AAAAAAD9AAoAAwADAD4ABwAA AP0ACgADAAQAPgAPAAAA/QAKAAMABQA+ABEAAAD9AAoAAwAGAD4ARgAAAP0ACgADAAcAPgAc AAAA/QAKAAMACAA+AB8AAAD9AAoAAwAJAD4AIgAAAP0ACgADAAoAPgAkAAAA/QAKAAMACwA+ ACYAAAD9AAoAAwAMAD4AKAAAAP0ACgADAA0APgAuAAAA/QAKAAMADgA+AC8AAAD9AAoAAwAP AD4AMwAAAP0ACgADABAAPgA1AAAA/QAKAAMAEQA+ADcAAAD9AAoAAwASAD4APQAAAP0ACgAD ABMAPgA/AAAA/QAKAAQAAAA+AEsAAAD9AAoABAABAD4ARQAAAP0ACgAEAAIAPgAOAAAA/QAK AAQAAwA+AA0AAAD9AAoABAAEAD4AEAAAAP0ACgAEAAUAPgAWAAAA/QAKAAQABgA+ABsAAAD9 AAoABAAHAD4AHgAAAP0ACgAEAAgAPgAhAAAA/QAKAAQACQA+ACMAAAD9AAoABAAKAD4AJQAA AP0ACgAEAAsAPgAnAAAA/QAKAAQADAA+AC0AAAD9AAoABAANAD4AMgAAAP0ACgAEAA4APgAx AAAA/QAKAAQADwA+ADQAAAD9AAoABAAQAD4ANgAAAP0ACgAEABEAPgA8AAAA/QAKAAQAEgA+ AD4AAAD9AAoABAATAD4AQAAAAP0ACgAFAAAAPgBKAAAA/QAKAAUABQA+ACkAAAD9AAoABQAM AD4AKQAAAP0ACgAFABEAPgBIAAAA/QAKAAUAEgA+AEkAAAD9AAoABgAAAD4AAQAAAP0ACgAG AAEAPgBCAAAA/QAKAAYAAgA/AAgAAAD9AAoABgADAD8ADAAAAP0ACgAGAAQAPwAMAAAA/QAK AAYABQA/ABIAAAD9AAoABgAGAD8AGAAAAP0ACgAGAAcAPwAIAAAA/QAKAAYACAA/AAgAAAD9 AAoABgAJAD8AGAAAAP0ACgAGAAoAPwAIAAAA/QAKAAYACwA/AAgAAAD9AAoABgAMAD8AKgAA AP0ACgAGAA0APwAYAAAA/QAKAAYADgA/AAgAAAD9AAoABgAPAD8ACAAAAP0ACgAGABAAPwAI AAAA/QAKAAYAEQA/ADgAAAD9AAoABgASAD8ACAAAAP0ACgAGABMAPwAIAAAA/QAKAAcAAAA+ AAIAAAD9AAoABwABAD4AQwAAAP0ACgAHAAIAPgAJAAAA/QAKAAcAAwA/AAkAAAD9AAoABwAE AD8ACQAAAP0ACgAHAAUAPwAUAAAA/QAKAAcABgA+ABoAAAD9AAoABwAHAD8ACQAAAP0ACgAH AAgAPwAJAAAA/QAKAAcACQA+ABoAAAD9AAoABwAKAD8ACQAAAP0ACgAHAAsAPwAJAAAA/QAK AAcADAA/ACsAAAD9AAoABwANAD8AGgAAAP0ACgAHAA4APwAJAAAA/QAKAAcADwA/AAkAAAD9 AAoABwAQAD8ACQAAAP0ACgAHABEAPwA5AAAA/QAKAAcAEgA/AAkAAAD9AAoABwATAD8ACQAA AP0ACgAIAAAAPgADAAAA/QAKAAgAAQA+AEcAAAD9AAoACAACAD8ACgAAAP0ACgAIAAMAPwAJ AAAA/QAKAAgABAA/AAoAAAD9AAoACAAFAD8AEwAAAP0ACgAIAAYAPwAZAAAA/QAKAAgABwA/ AB0AAAD9AAoACAAIAD8AIAAAAP0ACgAIAAkAPwAZAAAA/QAKAAgACgA/ACAAAAD9AAoACAAL AD8AIAAAAP0ACgAIAAwAPwAKAAAA/QAKAAgADQA/ABkAAAD9AAoACAAOAD8AIAAAAP0ACgAI AA8APwAgAAAA/QAKAAgAEAA/ACAAAAD9AAoACAARAD8AOgAAAP0ACgAIABIAPwAgAAAA/QAK AAgAEwA/ACAAAAD9AAoACQAAAD4ABAAAAP0ACgAJAAEAPgBEAAAA/QAKAAkAAgA/AAgAAAD9 AAoACQADAD8ACAAAAP0ACgAJAAQAPwAIAAAA/QAKAAkABQA/ABUAAAD9AAoACQAGAD8AFwAA AP0ACgAJAAcAPwAIAAAA/QAKAAkACAA/AAwAAAD9AAoACQAJAD8AFwAAAP0ACgAJAAoAPwAM AAAA/QAKAAkACwA/AAwAAAD9AAoACQAMAD8ALAAAAP0ACgAJAA0APwAXAAAA/QAKAAkADgA/ AAgAAAD9AAoACQAPAD8ACAAAAP0ACgAJABAAPwAIAAAA/QAKAAkAEQA/ADsAAAD9AAoACQAS AD8ACAAAAP0ACgAJABMAPwAIAAAA/QAKAAoAAAA+AAUAAAD9AAoACgABAD4AQgAAAP0ACgAK AAIAPwALAAAA/QAKAAoAAwA/AAYAAAD9AAoACgAEAD8ABgAAAP0ACgAKAAcAPwALAAAA/QAK AAoACAA/AAYAAAD9AAoACgAKAD8ABgAAAP0ACgAKAAsAPwAGAAAA/QAKAAoADAA/AAYAAAAB AgYACgANAD8A/QAKAAoADgA/ADAAAAD9AAoACgAPAD8AMAAAAP0ACgAKABAAPwAwAAAA/QAK AAoAEgA/ADAAAAD9AAoACgATAD8AMAAAAL4ACgALAAYAPwA/AAcAAQIGAA0ABQA/AAECBgAN ABEAPwABAgYAEAAIAD8A1wAaAKwIAADIAAoBGAFGABgBGAEYARgB3AAOABQAPgISALYGAwAA AEAAAAAAAH0AfQAAAMgIEQDICAAAAABAAAAAAAAIAAAAAKAABAAFAAQAHQAPAAMDAAAAAAAB AAMAAwAAAJkAAgDVGWcIFwBnCAAAAAAAAAAAAAACAAH/////A0QAAAoAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA AAADAAAA/v///wUAAAD+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1Zwu GxCTlwgAKyz5rjAAAADEAAAACQAAAAEAAABQAAAADwAAAFgAAAAXAAAAZAAAAAsAAABsAAAA EAAAAHQAAAATAAAAfAAAABYAAACEAAAADQAAAIwAAAAMAAAAnwAAAAIAAAAQJwAAHgAAAAQA AAAAAAAAAwAAAAAADgALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAA BwAAAFNoZWV0MQAMEAAAAgAAAB4AAAALAAAAV29ya3NoZWV0cwADAAAAAQAAAAAAAAAAAAAA AAAAAAAAAQD+/wIAAQD/////IAgCAAAAAADAAAAAAAAARiQAAABNaWNyb3NvZnQgRXhjZWwg OTcgLSAyMDA0IFdvcmtzaGVldAD+////OEZJQg4AAABFeGNlbC5TaGVldC44AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAADCgEA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAANQQAAAIAAAAAQAAAEgA AAAEAAAAUAAAAAgAAABkAAAAEgAAAHgAAAAMAAAAnAAAAA0AAACoAAAAEwAAALQAAAARAAAA vAAAAAIAAAAQJwAAHgAAAAwAAABTdGV2ZSBTaGVuZwAeAAAADAAAAFN0ZXZlIFNoZW5nAB4A AAAcAAAATWljcm9zb2Z0IE1hY2ludG9zaCBFeGNlbAAAAEAAAAAAGGUMZSnNAUAAAAAwhnZU JirNAQMAAAAAAAAARwAAABAQAAD+////UElDVBAIAAAAAABHAIAAEQL/DAD//gAAAEgAAABI AAAAAAAAAEcAgAAAAAAAHgABAAqAAYABf/9//wCa/wAAAIEAAAAAAABHAIAAAAADAAAAAABI AAAASAAAABAAEAADAAUAAAAQB8giaAAAAAAAAAAAAEcAgAAAAAAARwCAAAAAKQBrW/hvewFr WnOc5ne9AXOcc5zmd70Ab3vld70Bb3tve+Z3vQFrWn//AC0Ab3v5c5wCd71e93e95n//AVrW UpTmf/8Bc5x73uZ//wFKUkpS5n//AW97f/8ANwBrW/tvewRznHvef/9a1ne953//A3veUpRG MXve53//AXOce97mf/8CSlJSlHve53//AW97f/8ANQBrWvtvewR3vXvee95WtXe953//A3Oc f/93vXOc53//AXOce97mf/8BXvde9+Z//wFve3//AB77ZzkAXvf+VrUBWtZznMl73gFve3e9 yXveAWtaf/8AGQBve/hznAFve3e9yXveAHe9yHveAXOcf/8AGQB3vfh//wF73nveyX//AHve yH//AXe9f/8AIQB3vf5//wF3vUpS/X//AXvee97Jf/8Ae97If/8Bd71//wAfAHe9/X//AE5z /X//AXvee97Jf/8Ae97If/8Bd71//wAjAHe9/n//AnveSlJ73v5//wF73nveyX//AHveyH// AXe9f/8AIwB3vf5//wJ73nOce97+f/8Be9573sl//wB73sh//wF3vX//ABH2a1rId70Ac5zI d70Bc5x//wAZAHe9+H//AXvee97Jf/8Ae97If/8Bd71//wAjAHe9/n//Am97VrVve/5//wF7 3nveyX//AHveyH//AXe9f/8AIQB3vf1//wFjGGta/n//AXvee97Jf/8Ae97If/8Bd71//wAh AHe9/n//AW97Yxj9f/8Be9573sl//wB73sh//wF3vX//ACMAd73+f/8CZzlWtW97/n//AXve e97Jf/8Ae97If/8Bd71//wAZAHe9+H//AXvee97Jf/8Ae97If/8Bd71//wAR9mtayHe9AHOc yHe9AXOcf/8AIQB3vf5//wF73nOc/X//AXvee97Jf/8Ae97If/8Bd71//wAjAHe9/n//Ane9 WtZrWv5//wF73nveyX//AHveyH//AXe9f/8AIwB3vf5//wJ73l73Zzn+f/8Be9573sl//wB7 3sh//wF3vX//ACMAd73+f/8Cb3ta1nOc/n//AXvee97Jf/8Ae97If/8Bd71//wAZAHe9+H// AXvee97Jf/8Ae97If/8Bd71//wAU9mc5AHOcyXe9AHOcyHe9AXOcf/8AGQB3vfh//wF73nve yX//AHveyH//AXe9f/8AGQB3vfh//wF73nveyX//AHveyH//AXe9f/8AGQB3vfh//wF73nve yX//AHveyH//AXe9f/8AMQB3vfh//wF73nveyX//AHve83//CXOcTnNGMVrWXvd//3//TnNO c2MY4H//AXe9f/8ATwB3vfh//wF73nveyX//G3vef/9Oc05zc5xSlE5zYxh3vU5za1p3vX// VrVOc2taf/9CEH//Pe9//3//Pe9//0YxZzlSlFrW43//AXe9f/8ATwB3vfh//wF73nveyX// G3vef/8973e9Pe81rUpSWtY97y1rRjF//3//RjFrWlrWf/9CEH//Pe9//3//Pe9//1KUWtZC EFKU43//AXe9f/8ATwB3vfh//wF73nveyX//G3vef/9CEHe9SlI1rUIQc5wpSmtaOc5//3// Pe85zlrWf/9CEH//LWtCEF73JSlCED3vZzlGMT3v43//AXe9f/8AMQB3vf1//wFrWne9/n// AXvee97Jf/8Ae971f/8CTnNOc2ta93//AHve4n//AXe9f/8AKwB3vf5//wJ3vU5zb3v+f/8B e9573sl//wB73vV//wFznGta1n//AXe9f/8AIwB3vf5//wJSlEpSXvf+f/8Be9573sl//wB7 3sh//wF3vX//ACEAd739f/8Bb3tznP5//wF73nveyX//AHveyH//AXe9f/8AGQB3vfh//wF7 3nveyX//AHveyH//AXe9f/8AEfZrWsh3vQBznMh3vQFznH//ABkAd734f/8Be9573sl//wB7 3sh//wF3vX//ABkAd734f/8Be9573sl//wB73sh//wF3vX//ADcAd734f/8Be9573sl//wJ7 3n//d733f/8Bd713vfN//wN3vX//f/973v1//wB3ve1//wF3vX//AIcAd734f/8Be9573sl/ /zt73n//Pe9e93e9Na1GMWtaZzlrWn//c5xrWmc5UpRve173f/9ve2MYd7173m97e953vWMY a1pSlF73RjFznF73UpRrWmc5f/9//2MYd71jGH//ZzlnOXveZzlrWne9Zzlve3//f/9ve2c5 f/9nOXe9f/9//3e9f/8AhwB3vfh//wF73nveyX//O3vef/8xjGc5UpQ970pSZzlGMU5za1pz nE5zc5xjGDnOZzlOcy1rQhBKUlKUHOdSlEYxa1oxjFa1ZzlGMUIQYxhSlC1rTnN//3//RjFC EGtaZzlOcylKYxhSlD3vVrVa1kIQf/973kIQWtZWtTnOe95//3//d71//wCFAHe9+H//AXve e97Jf/82e95//0IQd71OczWtTnNe90IQRjFve297TnNSlH//RjF3vU5zOc5WtWtaLWte9y1r VrVa1i1rWtZe90YxQhBa1k5zUpQ1rW97c5xGMT3vYxhOc0IQMYxe92MYRjFWtW97RjFznHe9 Pe9SlFrWSlL+f/8Bd71//wCFAHe9+H//AXvee97Jf/82e95//3Ocf/93vWtae95jGEpSb3t/ /3Ocd71znH//d71//3e9c5xnOX//c5x//3Oca1pe9znOf/9ve3e9d71rWne9b3trWnved713 vXveZzl//2c5c5x3vXved713vX//d713vXvec5xrWn//d73+f/8Bd71//wArAHe9+H//AXve e97Jf/8Ae977f/8Be95znPJ//wJ73lKUb3vif/8Bd71//wAZAHe9+H//AXvee97Jf/8Ae97I f/8Bd71//wBVAHe9+H//AXvee97Jf/8Ae979f/8BXvdznPx//wF3vV73+X//AkpSYxh73vl/ /wBa1v5//wFve2c5/H//BE5zf/9//3e9Xvf8f/8AXvf+f/8Bd71//wCFAHe9+H//AXvee97J f/82e95//1KURjFe905za1pGMV73TnNGMV73VrVve0YxSlJjGEYxUpRa1kpSVrVCEF73c5xG MVKUWtZGMWMYSlJCEGc5KUpe90pSYxhWtWtaRjFOc2c5RjFKUj3vRjFe91rWa1pGMT3vXvd/ /1a1Wtb+f/8Bd71//wCFAHe9+H//AXvee97Jf/82e95//z3vd71Oc05zPe9WtUYxPe9//0Yx TnNznE5zMYxWtW97RjFKUnveRjFCEE5zRjF3vXOcVrVWtUIQRjF3vVKUQhBjGEYxXvdSlGc5 UpQxjEYxf/8970Yxf/8971KUSlJ//z3vTnN73kIQRjH+f/8Bd71//wCLAHe9+H//BHvee95r Wk5zWtbMf/82e95//0pSSlI972c5WtZSlFa1SlJ//05zVrVnOU5zOc5WtUYxSlJKUk5zTnNK Ula1ZzlKUkpSRjFWtUpSUpR73la1Pe9WtVKUTnNa1lKUVrU5zl73UpQxjEpSUpRWtVa1a1pK UilKYxhKUj3vUpT+f/8Bd71//wBnAHe9+H//E3vee94972taYxh73k5zVrVnOXe9Xvde905z XvdOc3OcTnNSlHe9a1rbf/8Ee95//05zTnNve/Z//wRe93Ocf/9WtXve7X//Al73UpRa1v1/ /wJrWlKUTnP6f/8Bd71//wA7AHe9+H//Envee95ve173Na1KUm97SlJOc297RjFGMX//RjF/ /1a1Pe9CEHe92n//AHveyH//AXe9f/8AgwB3vfh//xN73nveRjFGMTnOZzk97znOYxg97zGM RjF//0IQRjFa1jnOPe9ve2c523//CHvef/9//3e9WtZ//3//c5xe9/p//wFWtXve/n//BT3v d71//3//UpROc/5//wVCEH//Zzla1mtad737f/8EXvdjGGtaRjFOc/Z//wF3vX//AIUAd734 f/8De9573n//e978f/8Ae979f/8Ae97Wf/8ue95//1KUQhBSlEpSQhBvey1rQhB73kIQSlJ3 vUIQUpRKUmtaXvd//297KUpWtX//WtZGMUIQf/9//173Na1//0IQUpRnOXOcQhA97297QhBG MXvePe9e92c5f/897/Z//wF3vX//AHkAd734f/8Be9573sl//zB73n//Pe9znEIQLWs9705z UpRa1j3vb3tOcznOe95CEEpSKUp//05za1pG MUIQf/9GMUYxQhBjGFrWf/9GMX//c5xSlFrW a1pOczGMWtZe90IQf/9nOV73f/9WtVa1Xvde9/h//wF3vX//AHYAd734f/8Be9573sl//y17 3n//Oc5rWkYxRjFrWmMYSlJOc0pSYxhGMUYxb3s970pSVrVe93Oce95GMT3vd70970YxQhB3 vXe9f/9GMX//c5xSlFrWUpRSlEYxVrVjGEIQf/9nOV73YxhKUv53vfh//wF3vX//AHMAd734 f/8Be9573sl//xp73n//ZzlSlG97XvdSlHveVrVa1n//UpRe93//TnNnOWtaf/9jGH//f/9r Wm97TnNrWmtaZzn+f/8Qa1p//3veb3tWtWtaTnNa1m97c5xnOX//d71znGc5TnNSlPZ//wF3 vX//AB8Ad734f/8Be9573sl//wB73uB//wBa1up//wF3vX//ACMAd734f/8Be9573sl//wB7 3vR//wJ73nOce97Yf/8Bd71//wA5AHe9+H//AXvee97Jf/8Qe95//3OcYxh//2taYxh//3// b3te93//c5xe90pSLWt3vdh//wF3vX//ADcAd734f/8Be9573sl//w973nveKUpGMVKUNa1S lGtaf/81rXOcRjE5zmMYTnNCENd//wF3vX//ADcAd734f/8Be9573sl//w973nveNa1nOWMY RjFe92c5d705znveRjE5zmtaUpRGMdd//wF3vX//AD0Ad739f/8Ad739f/8Be9573sl//w97 3n//YxhKUnveZzlznHe9Yxg5zkpSe95nOU5za1pnOdd//wF3vX//ACkAd73+f/8CYxhe93Oc /n//AXvee97Jf/8Ae975f/8AWtbRf/8Bd71//wAjAHe9/n//AnOcUpRznP5//wF73nveyX// AHveyH//AXe9f/8AIwB3vf5//wJ73mMYYxj+f/8Be9573sl//wB73sh//wF3vX//ACEAd73+ f/8Be95znP1//wF73nveyX//AHveyH//AXe9f/8AEfZrWsh3vQBznMh3vQFznH//ABkAd734 f/8Be9573sl//wB73sh//wF3vX//AAOBf/8A/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAGIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --B_3422423098_9271252-- --B_3422423098_9263511 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFK9DuTaXEfiuMROhC4svLyO61tL/MBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYxMzE2MDQ1OFowDQYJ KoZIhvcNAQEBBQAEggEAeyJJhxD1+dn3Hg/XkO8sS7gDd1o/VE/p4HDYwD4ni8c6FX70RM+2 jXUlzNUsHWcUkdlU7R8hm221RG3ua1vakpw/CBvUGXoUQFvyzO9W/8ajJOJJqDs611y/zbdo UmYNJ1aNrcPl/ifGKVqJhI1v8yaOK9rYshdBcMrVYUHDskq3l2t27SpjiednOP5prK7Sw4Cj SJTo3TKDX6/Tta8qrdinnyTCvULoaQgs5okx4+e0alwxPm18INbMUSTJUvLrlm3dBbPLEHbn JHFxFOcbhJ1Th0HfZHNp7Gaii8pAIAI56JZxfrEpI7ifhy36uM8jmWpzsrDQ85CAqKZN4lOU SQ== --B_3422423098_9263511-- From steve.sheng@icann.org Wed Jun 13 09:17:31 2012 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 2B68221F84EC for ; Wed, 13 Jun 2012 09:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Ensl-ePp1+aL for ; Wed, 13 Jun 2012 09:17:28 -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 159B321F852C for ; Wed, 13 Jun 2012 09:17:28 -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; Wed, 13 Jun 2012 09:17:27 -0700 From: Steve Sheng To: Ning Kong , 'Olaf Kolkman' , 'Web Extensible Internet Registration Data Service Working Group' Date: Wed, 13 Jun 2012 09:17:25 -0700 Thread-Topic: [weirds] Divide and Conquer Thread-Index: Ac1JgAZV97RWWEsQS2+ou15hjCEiFw== Message-ID: In-Reply-To: <01b501cd494a$20482920$60d87b60$@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3422423845_9320442" MIME-Version: 1.0 Subject: Re: [weirds] Divide and Conquer 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, 13 Jun 2012 16:17:31 -0000 --B_3422423845_9320442 Content-type: multipart/alternative; boundary="B_3422423845_9360766" --B_3422423845_9360766 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Thanks Ning for the offer, let's discuss off-list on how to improve this. Let's also reach out to Frederico and Ray to see how we can effectively survey the the ccTLDs. Steve From: Ning Kong To: Steve Sheng , 'Olaf Kolkman' , 'Web Extensible Internet Registration Data Service Working Group' Subject: RE: [weirds] Divide and Conquer > Hi Steve, > =20 > Thanks for your contribution! I hope this work can be continued and I=B9d l= ike > to join.=20 > I believe the output of this work can help us to improve the response dra= ft > (e.g. finding out some better names for terms of objects, and even specif= ying > an absolutely minimum data element set in a response). > =20 > =20 > Cheers, > Ning > =20 >=20 > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf = Of > Steve Sheng > Sent: Wednesday, June 13, 2012 2:39 AM > To: Olaf Kolkman; Web Extensible Internet Registration Data Service Worki= ng > Group > Subject: Re: [weirds] Divide and Conquer > =20 >=20 > Hello Olaf and all, >=20 > =20 >=20 > From: Olaf Kolkman > To: Web Extensible Internet Registration Data Service Working Group > > Subject: [weirds] Divide and Conquer >=20 > =20 >>=20 >> =20 >>=20 >> Dear Colleagues, >>=20 >> =20 >>=20 >> Murray and myself have been talking to a few active working participants= , >> with the area director, and among ourselves. >>=20 >> =20 >>=20 >> Based on those discussion, and after coordination with Murray, I would >>=20 >> like to make two proposals for getting work done: >>=20 >> =20 >>=20 >> =20 >>=20 >> 1. Working group drafts and output documents. >>=20 >> =20 >>=20 >> Murray has already called for adaption of a number of documents. Those >>=20 >> documents are all input documents. The output of the working group >>=20 >> might find its way into a different set of documents. >>=20 >> =20 >>=20 >> A structure that has been proposed to me by Scott H. and Andy N. seems >> reasonable:=20 >>=20 >> =20 >>=20 >> 1. For all implementers: >>=20 >> 1.1 The use of HTTP >>=20 >> 1.2 Details of Redirecting >>=20 >> =20 >>=20 >> 1.3 Specification of generic json responses and extensibility mechanis= m >>=20 >> 1.4 Specification of generic xml responses and extensibility mechanism >>=20 >> =20 >>=20 >> 2.Numbers: >>=20 >> 2.1 specification of queries >>=20 >> 2.2 specification of specific number-responses json responses >>=20 >> =20 >>=20 >> 3.Names: >>=20 >> 3.1 specification of queries >>=20 >> 3.2 specification of specific name-related json responses >>=20 >> and/or >>=20 >> 3.3 specification of specific number-related xml responses >>=20 >> =20 >>=20 >> =20 >>=20 >> It might be that 1.3 and 1.4 are so minimal that the information >>=20 >> therein is better (dublicated) in 2.2, 3.2, and 3.3. >>=20 >> =20 >>=20 >> =20 >>=20 >> =20 >>=20 >> 2. Dealing with the data framework. >>=20 >> =20 >>=20 >> I believe that the data framework for the domain name space is one of >>=20 >> the biggest elephants in the room and that making sure we converge to >>=20 >> a comon understanding is critical to success of the working group. It >>=20 >> seems that an enumeration of all data elements that are comonly in use >>=20 >> including comonly used formats. Ray Bellis and Frederico Neves >>=20 >> have made a start with that in a spreadsheet at >>=20 >> https://docs.google.com/spreadsheet/ccc?key=3D0AjZQpmBlboLWdFBfdERTQm9QQWd= rejNt >> aTBhNmI3SHc#gid=3D0 >>=20 >> and it seems that we can use that as a basis. >=20 > =20 >=20 > I have done an inventory of the data elements that current gTLD registrie= s' > Registration Data Directory Service (RDDS) output. >=20 > =20 >=20 > Attached please find the spreadsheet. This inventory contains 159 data > elements that are: >=20 > - actual RDDS output of 18 gTLD registries >=20 > - new gTLD RDDS output as specified by ICANN applicant guidebook >=20 > =20 >=20 > Among these 159 data elements, 75 are common elements, 84 are registry > specific elements. This distinction is also highlighted in the excel shee= t. >=20 > =20 >=20 > Finally, I have also harmonized data labels from different gTLD registri= es > that refer to the same element. >=20 > =20 >=20 > Note, the scope of this exercise is limited to domain queries for gTLD > registries, it does not cover querying name server and registrars, nor do= es it > cover registrar RDDS in the case of thin registries. If people find this > preliminary exercise useful, I can continue to work on this, and also inv= ite > others to participate to get this done for gTLDs as well as ccTLDs. >=20 > =20 >=20 > Steve >=20 > =20 >>=20 >> =20 >>=20 >> Once we have a relatively complete enumeration of all data elements >>=20 >> that are commonly in use we continue with trying to get convergence on >>=20 >> their presentation format (it seems we have to do that irrespective of >>=20 >> encaptulation in json or xml). >>=20 >> =20 >>=20 >> One of the important questions that might help to converge while >>=20 >> defining data elements and while determining such data-element can be >>=20 >> queried is whether the query-response protocol is direct match, or >>=20 >> search. The charter is not clear about this, I believe. Hence I >>=20 >> propose that we focus on the low-hanging fruit of direct-match and >>=20 >> that we circumvent any questions of the type 'what type of matching >>=20 >> algorithm to apply?' >>=20 >> =20 >>=20 >> For instance, if we have a person name as a data element then a query >>=20 >> for "Kolkman" might not yield a unique result and some matching >>=20 >> algorithm may need to be applied, the use of a NIC-handle might be >>=20 >> more appropriate in such cases. By agreeing on the principle that we >>=20 >> work towards direct-match we know how to focus our energy. >>=20 >> =20 >>=20 >> How does this sound as a first order approach? If folk like this we'll >>=20 >> try to come up with a way to capture the information in the spreadsheet >>=20 >> (or other appropriate tool) and work forward in a structured way. >>=20 >> =20 >>=20 >> --Olaf=20 >>=20 >> WEIRDS co-chair >>=20 >> =20 >>=20 >> =20 >>=20 >> NLnet >> LabsOlaf M. Kolkman >> www.NLnetLabs.nl >>=20 >> olaf@NLnetLabs.nl >>=20 >> Science Park 400, 1098 XH Amsterdam, The Netherlands >>=20 >> =20 >> =20 >> =20 --B_3422423845_9360766 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Thanks Ning for the offer, l= et's discuss off-list on how to improve this. Let's also reach out to Freder= ico and Ray to see how we can effectively survey the the ccTLDs. 
=

Steve

Fr= om: Ning Kong <nkong@cnnic.cn= >
To: Steve Sheng <steve.sheng@icann.org>, 'Olaf Kolkman' = <olaf@nlnetlabs.nl>, 'Web Exten= sible Internet Registration Data Service Working Group' <weirds@ietf.org>
S= ubject: RE: [weirds] Divide and Conquer

Hi Steve,=

 

Thanks= for your contribution! I hope this work can be continued and I’d like= to join.

I believe the output of this work = can help us to improve the response draft (e.g. finding out some better name= s for terms of objects, and even specifying an absolutely minimum data element set in a response).

 

 

Cheers,

<= span lang=3D"EN-US" style=3D"color: black; font-family: Arial, sans-serif; ">Nin= g

 

From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of Steve Sheng
Sent: Wednesday, June 13, 2012 2:= 39 AM
To: Olaf Kolkman; Web Extensible Internet Registration Data = Service Working Group
Subject: Re: [weirds] Divide and Conquer

&= nbsp;

Hello Ola= f and all, 

 

From: Olaf Kolkman <olaf@nlnetlabs.nl>
To: Web Extensible Internet Registr= ation Data Service Working Group <weirds= @ietf.org>
Subject: [weirds] Divide and Conquer<= /span>

 

 

Dear Colleagues,

 

Murray and myself have been ta= lking to a few active working participants, with the area director, and amon= g ourselves. 

 

<= span lang=3D"EN-US" style=3D"font-size: 10.5pt; color: black; font-family: Calib= ri, sans-serif; ">Based on those discussion, and after coordination with Mur= ray, I would

like to make two proposals for getting work done:=

 

 <= /span>

1. Working grou= p drafts and output documents.

 

Murray has already called for adaption of a nu= mber of documents. Those

documents are all input documents. The output of the wo= rking group

might find its way into a different set of documents.

 <= /span>

A structure tha= t has been proposed to me by Scott H. and Andy N. seems reasonable: 

&= nbsp;

1. = For all implementers:

<= span lang=3D"EN-US" style=3D"font-size: 10.5pt; color: black; font-family: Calib= ri, sans-serif; ">  1.1 The use of HTTP

  1.2 Details of Redirecting

=  

&n= bsp; 1.3 Specification of generic json responses and extensibility mechanism=

&nb= sp; 1.4 Specification of generic xml responses and extensibility mechanism

=  

2.= Numbers:

  2.1 specification of queries

  2.2 specification of specific nu= mber-responses json responses

 

3.Names:

  3.1 specification of queries

  3.2= specification of specific name-related json responses 

and/or

  3.3 speci= fication of specific number-related xml responses

 

 

It might be that 1.3 and= 1.4 are so minimal that the information

therein is better (dublicated) in 2.2, = 3.2, and 3.3.

 

 

 

= 2. Dealing with the data framework.

=

 <= /p>

I believe that the dat= a framework for the domain name space is one of

<= div>

the biggest elephants in the roo= m and that making sure we converge to

a comon understanding is critical to succe= ss of the working group. It

seems that an enumeration of all data elements that = are comonly in use

including comonly used formats. Ray Bellis and Frederico Neve= s

ha= ve made a start with that in a spreadsheet at

https://docs.google.com/spreadsheet/ccc?key=3D0AjZQpmBlboLWdFBfdERT= Qm9QQWdrejNtaTBhNmI3SHc#gid=3D0

and it seems that we can use that as a basis.<= o:p>

<= p class=3D"MsoNormal"> 

I have done an inventory of the da= ta elements that current gTLD registries' Registration Data Directory Servic= e (RDDS) output. 

=  

Attached please find the spreadsheet. This invent= ory contains 159 data elements that are: 

  - actual RDDS output of 18= gTLD registries

  - new gTLD RDDS output as specified by ICANN applicant g= uidebook 

 

Among these 159 data elements, 75 are common elements,  8= 4 are registry specific elements. This distinction is also highlighted in th= e excel sheet. 

 

Finally, I have also harmonized  data labels from d= ifferent gTLD registries that refer to the same element.  

 

Note, the sco= pe of this exercise is limited to domain queries for gTLD registries, it doe= s not cover querying name server and registrars, nor does it cover registrar RDDS in the case of thin registries. If people find thi= s preliminary exercise useful, I can continue to work on this, and also invi= te others to participate to get this done for gTLDs as well as ccTLDs.  = ;

 

Steve

=

 

Once we have a relatively co= mplete enumeration of all data elements

that are commonly in use we continue wit= h trying to get convergence on

their presentation format (it seems we have to do= that irrespective of

<= span lang=3D"EN-US" style=3D"font-size: 10.5pt; color: black; font-family: Calib= ri, sans-serif; ">encaptulation in json or xml).

=

 

One of the important questio= ns that might help to converge while

defining data elements and while determinin= g such data-element can be

queried is whether the query-response protocol is dir= ect match, or

search. The charter is not clear about this, I believe. Hence I

propos= e that we focus on the low-hanging fruit of direct-match and

that we circumvent = any questions of the type 'what type of matching

=

algorithm to apply?' =

&nb= sp;

For i= nstance, if we have a person name as a data element then a query<= /span>

for "Kolkman" m= ight not yield a unique result and some matching

=

algorithm may need to be applie= d, the use of a NIC-handle might be

more appropriate in such cases. By agreeing = on the principle that we

work towards direct-match we know how to focus our ener= gy.

=  

try to= come up with a way to capture the information in the spreadsheet=

(or other appr= opriate tool) and work forward in a structured way.

 

=

--Olaf 

  WEIRDS co= -chair

 

<= /div>

 

NLnet
= Labs

Ol= af M. Kolkman

Science Park 400, 1098 XH Amsterdam, The = Netherlands

=  

<= p class=3D"MsoNormal"> 

 

 --B_3422423845_9360766-- --B_3422423845_9320442 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITmwYJKoZIhvcNAQcCoIITjDCCE4gCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EWcwggbiMIIFyqADAgECAhABZMwilD7GxArmntmcL5R/MA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjA2MDcwMDAw MDBaFw0xNTA2MDcxMjAwMDBaMIGPMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEUMBIGA1UEAxMLU3RldmUgU2hl bmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDAk0LP2kd68QahDa0JHYITr25S nDBvdGo1ipsN1/W/XOD3D/TsHIwLW6fJGxggQe20WSP0z4C2bAwxm/86a7LgTSHFVHID6NCU wI3FjTukn1NKepT1qLFYJ+F+6Fr+PGXxAqkHjgtxvH6D6/i6CBVx23nhikAZZ9kohGXmrAeu q7WfAIKziZel8gESFvnlwl0ddgUB2onbPnytNSTkE7YadrP+seY5q8pH52M5m5BL5j6Ov6DS ix78Yx7rqRclE2MCTsRtlxy9MCQMf95/5Jhy+ZR6Hm+7kSXdosckMmqitzqw/sE6FNA+ChLQ PYA4KkmnRFZXjNLy0z3CqNOPj4hPAgMBAAGjggNkMIIDYDAfBgNVHSMEGDAWgBQVABIrE5iy mQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUz5w5ABV+GwM+WrkNqgAws9jssIwwIAYDVR0RBBkw F4EVc3RldmUuc2hlbmdAaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggr BgEFBQcDBAYIKwYBBQUHAwIwfQYDVR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgw ggG0BgpghkgBhv1sBAECMIIBpDA6BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5j b20vc3NsLWNwcy1yZXBvc2l0b3J5Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkA IAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8A bgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUA IABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUA bAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgA IABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4A YwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUA bgBjAGUALjB3BggrBgEFBQcBAQRrMGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2lj ZXJ0LmNvbTBBBggrBgEFBQcwAoY1aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEQ0EtMS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEA zZA8H8eHQfdut5RjlHklXuWQYdnPAwmXRjcuqwhmvlsAghGxLyfQ6+glnd3TsSue+ighPszj 4i1ryRnBN4/SkywV+5gcP88BU94zAZJvSxmNeD5kR9HjZsL44PrpvgtDv0Q4Ap6PA3K9pals EPORzu1f+QcLFmSY/1E6nunOOjhAaSKwLKU8ThkwUmczI9Wm74SVNMjWJZlsHJsG4AoEUJe7 HG04zMo3/vadmoywbDHtmQjLZWNu/1OvBH0xaXnPW+meS8HaPALX6wDKPeUCxWq4/GLEqUWV L6IKJ3yRjbYrAjjGu1P4KTv9UsH0iEowiq+7ewjbD+dXexWsaXh8bTCCBsIwggWqoAMCAQIC EAoE3yF0XU0rjOozcgUAUOkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAw MDAwMFowYjELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEhMB8GA1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEG j8kz/E1FkVyBn+0snPgWWd+etSQVwpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYI A6sMNP4YSYL+x8cxSIB8HqIPkg5QycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkF l32jx0PdAug7Pe2xQaPtP77blUjE7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLO Bq6thG9IhJtPQLnxTPKvmPv2zkBdXPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcK J1Z8D2KkPzIUYJX9BwSiCQIDAQABo4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0 MDIGCCsGAQUFBwMBBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCC AcYGA1UdIASCAb0wggG5MIIBtQYLYIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRw Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9zc2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUH AgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBm AGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBj AGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBu AGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBl AG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBu AGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABi AHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEE cTBvMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKG O2h0dHA6Ly93d3cuZGlnaWNlcnQuY29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290 Q0EuY3J0MIGBBgNVHR8EejB4MDqgOKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGln aUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5j b20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+i vlcNK2cCzTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUF AAOCAQEAhGFOQR64dgQqtbbvj/JVhbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTk c61hXXatdDOKZtUjr0wfcm5F2XVAu6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5Wwg V7aBum+8s8KU7XYCgNl8zoWoHOzHQ0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1b fDGzdzXD5GP5aAqYB+dGOHeE0j6XvAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDes z+urWB/JiCP/NtQH6jRqR+qdlWyeKU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKf oAMCAQICEAzn4OUX2Eb+j+Vg/BvwMDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIG A1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMx MTExMDAwMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlx EqWu3CaUiKr0zvUgOShYYAz4gNqpFZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gy NnbM3t08qKLvavsh8lJh358g1x/isdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgv GP4oD7Ong9bDbkTAYTWWFv5ZnIt2bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgz bCLph9AyWqK6E4IR7TkXnZk6cqHm+qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKm VrO9spftqqfwt8WoP5UW0P+hlusIXxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYD VR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgw FoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6 ZJS/93Jm2DLkQnVirofr8tXZ3lazn8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLY Z4GE338JPJTmuCYsIL09syiJ91//IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVt X4kBtklbnwEFm6s9JcHMtn/C8W+GxvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83 fKlbbXrxEkZgg9cnBL5Lzpe+w2cqaBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKj JqEQcZ2t4sP5w5lRtysHCM4u5lCyp/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x ITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMQIQAWTMIpQ+xsQK5p7ZnC+UfzAJ BgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFDgHmZT9Z02mLFQgnZZYNHipTJPAMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDYxMzE2MTcyNVowDQYJ KoZIhvcNAQEBBQAEggEAfPSttxfC80MtU8baEgl79Gbov+7MFjWwrBFjll1yNUDovsDAECVi pXwjiNPMdigWkD6ta3+eK8zDwktONes739SpbwpgwsICFHgAn1VvkrQ5hQ4+SMSF+66R2tL7 q1WTwjuuqKCXYWnCg2inytoquh4r0uvRejbcX3A2cn5UD0AOfhnJYkJrT4OS3UryJBY69csD mk3gb/iNMbHbQ5d9SNWVktcsecLsKROpb3ALMFUmMXO1wD08es9fU3WBq09tHqom6bJMwASe x5Zeu42EFEXzqHrcJmT29NimQAWpDd9UiapxPa2xlHZ7n2I5M+48L6Y2mFQp0qvD2MNsCUYD Ww== --B_3422423845_9320442-- From bob@coldrain.net Wed Jun 13 10:26:58 2012 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 0E7E121F854D for ; Wed, 13 Jun 2012 10:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.138 X-Spam-Level: X-Spam-Status: No, score=-1.138 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3LutRzJKeRc for ; Wed, 13 Jun 2012 10:26:57 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE721F864D for ; Wed, 13 Jun 2012 10:26:56 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5DHQoGQ027547; Wed, 13 Jun 2012 13:26:50 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5DHQo2f027544; Wed, 13 Jun 2012 13:26:50 -0400 Date: Wed, 13 Jun 2012 13:26:50 -0400 (EDT) From: Bob Bruen To: John Levine In-Reply-To: <20120613155841.77939.qmail@joyce.lan> Message-ID: References: <20120613155841.77939.qmail@joyce.lan> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] lessons learned 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, 13 Jun 2012 17:26:58 -0000 Hi John, The show I meant was the writing of the RFC. I know that one does not have to follow standards, although generally industries do. Happily, The IETF has had a significant impact over the decades on how things work. And I would never question what you know or what you are aware of :) --bob On Wed, 13 Jun 2012, John Levine wrote: >> Now, it seems that the agenda of special interest groups run the >> process. I am not part of "the community" because I am considered a >> "data consumer" and in this case the "data providers" are running the >> show. ... > > I'm sorry, but this totally misunderstands what standards are and what > they can do. All an IETF standard can do is tell people how to > interoperate if they are already inclined to do so. WEIRDS can say > here's how a client can send a query that a server will understand, > and here's how a server can send a response that a client can parse. > That's it. > > Much though I would like to say the servers MUST answer all queries > without rate limiting and MUST NOT respond with redacted versions of > cruddy data, that's not how it works. Were we to say that, either the > servers would ignore those parts and rate limit and redact anyway, > most likely in ways that made it impossible for clients to tell what's > going on, or else would say that since WEIRDS doesn't let us follow > our policies, we can't use WEIRDS. > > Having written a WHOIS scraper that is over 2700 lines and still > growing, I'm acutely aware of how badly WHOIS works. A mechanically > queryable version of what we have now, while still far from ideal, > would be a considerable improvement. > > There are other places to have policy arguments. This isn't one. > > R's, > John > -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From sm@resistor.net Wed Jun 13 10:39:16 2012 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 0A31121F853E for ; Wed, 13 Jun 2012 10:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 tHKbl6OGMKkr for ; Wed, 13 Jun 2012 10:39:13 -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 99DE521F8534 for ; Wed, 13 Jun 2012 10:39:13 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5DHd4vQ024276; Wed, 13 Jun 2012 10:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339609150; i=@resistor.net; bh=sqdsdzJKW+CPvqVp9Po0raZD38LNrSLXw+B+Pbw+rBE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qJBEr5ZSqsKdkyfM2Z3Y30V8w399wpWI7i5NOrPnNB55koOf2lpTGKMR6QHT8qVB9 3X+JzxkFNSaApc+eMi1my5wuLKpKkenNSh5WnWDXAocNOiGGsnz3khO8+sB7kw1jD3 JjIt9WSCscAzNhow2V3nLSTgwxGtnZtAqO9sc5O8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339609150; i=@resistor.net; bh=sqdsdzJKW+CPvqVp9Po0raZD38LNrSLXw+B+Pbw+rBE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HQRWY/3/cCD4tgxTxFEj9Mm0gm6csLItBMheRW8f/5lmbySQPFouxXL8Nn3PyoQlS TZ0rQmYpsBP1bdR540qWBbt44kHqsFdatfIG/BQ47jP8sm/us+8meONaYjCShERYmB gMQdO5IysOmfRfU4MjeecwZEcWGcEU9SAckds4NA= Message-Id: <6.2.5.6.2.20120613100548.09c87fc0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 13 Jun 2012 10:28:44 -0700 To: Bob Bruen From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] lessons learned 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, 13 Jun 2012 17:39:16 -0000 Hi Bob, At 06:19 13-06-2012, Bob Bruen wrote: >Now, it seems that the agenda of special interest groups run the >process. I am not part of "the community" because I am considered a >"data consumer" and in this case the "data providers" are running >the show. The agenda has been set. Now it just gets implemented. According to the relevant BCPs I am an IETF participant as anyone else in this working group. I cannot stop special interest groups from considering me as X, Y or Z. I have read the working group charter as it explains the scope of the work to be performed. I have read that the Working Group Chairs see to the process details in a working group. Regards, -sm From alexandrsergeyev@gmail.com Wed Jun 13 20:46:06 2012 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 5886711E80A1 for ; Wed, 13 Jun 2012 20:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdbtExKyj+f3 for ; Wed, 13 Jun 2012 20:46:05 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88B6311E80B3 for ; Wed, 13 Jun 2012 20:46:02 -0700 (PDT) Received: by werb13 with SMTP id b13so1107632wer.31 for ; Wed, 13 Jun 2012 20:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=tznbZWHArMnFtnBbnmqwMUnTu1fd/SpVDRYhX8Ctzmg=; b=Dnbbs0JgxQq0c6qyJoWH+gpmIJ7I8oIo+qSQIQKhikQ3gzT9tvQHmIYeOj+9REonaB xkoXCjptWFs0jnd31gxOnqZHCHyztFvHwd9vvRHfKyUDpFeOhntQIYDsQpX8QlgYNzCd J41MUckr6PATcw9+O55n3l9ilbVkLO58Xu+/2Pr03dyG+CDDtiI9s26ksJAfXDYAwCnH 5gEvIzYJUBJq+2QBOWe0m5/HM2z2mQkqbhodhq7deFbd95X3IiRwtkMDU3YTPw7pm1db w8trP5/7n1v3sCwZmNkZi5JrqZiwXf+Q6bKmx/SUgKEAX+peCPR7jcW0/3lKJkNhqFzA ZYkw== MIME-Version: 1.0 Received: by 10.180.109.194 with SMTP id hu2mr568635wib.0.1339645561511; Wed, 13 Jun 2012 20:46:01 -0700 (PDT) Sender: alexandrsergeyev@gmail.com Received: by 10.216.49.16 with HTTP; Wed, 13 Jun 2012 20:46:01 -0700 (PDT) In-Reply-To: <4FD7A964.6040801@arin.net> References: <20120612155643.GI16548@mail.yitter.info> <20120612202423.75669.qmail@joyce.lan> <20120612203425.GO25201@mail.yitter.info> <4FD7A964.6040801@arin.net> Date: Wed, 13 Jun 2012 23:46:01 -0400 X-Google-Sender-Auth: grzx5hZpakWIkNyQ8h4An9aCI34 Message-ID: From: Alex Sergeyev To: Andy Newton , weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [weirds] decomposition and redaction, was FW: I-D Action X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 03:46:06 -0000 On Tue, Jun 12, 2012 at 4:41 PM, Andy Newton wrote: > On 06/12/2012 04:34 PM, Andrew Sullivan wrote: >> I thought we were doing REST, not >> REST-except-where-everything-is-inlined-then-work-hard? >>... > How is forcing a client to requery 3 or 4 times less cumbersome? I know it looks bad but doing 3-4 requests should not be a concern. Browsers do that all the time, weirds clients may handle it too. HTTP has keep-alive and all (name your programming language) libs can do that. -- Alex. From david.collier-brown@zylog.ca Mon Jun 11 11:48:15 2012 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 0575321F861B for ; Mon, 11 Jun 2012 11:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuNppq2rSdH8 for ; Mon, 11 Jun 2012 11:48:14 -0700 (PDT) Received: from mail1.treklogic.com (mail1.treklogic.com [207.245.223.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6426A21F846A for ; Mon, 11 Jun 2012 11:48:13 -0700 (PDT) Received: from [192.168.11.41] ([192.168.11.41]) (authenticated bits=0) by mail1.treklogic.com (8.14.3/8.13.4/Debian-3sarge3) with ESMTP id q5BIm72n001400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 11 Jun 2012 14:48:07 -0400 Message-ID: <4FD63DB0.3030601@zylog.ca> Date: Mon, 11 Jun 2012 14:49:20 -0400 From: David Collier-Brown Organization: Zylog Systems (Canada) Ltd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Ning Kong" , weirds@ietf.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 13 Jun 2012 22:43:14 -0700 Subject: [weirds] Re: I-D Action: draft-kong-dnrd-ap-response-json-00.txt (an a test) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: david.collier-brown@zylog.ca List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 18:51:44 -0000 As to terms, I find the more self-describing the better, so "roid" sounds undesirable *unless* it's a really well-known term of art. This is also a test to see if the list is down or just quiet (;-)) --dave Ning Kong wrote: | This is a 00 draft to describe a response format in JSON for name | registries. This document has been reviewed and improved by the design team. | The following issues are still needed to be further discussed. | 1) As for the naming of the terms, should we try to follow the EPP | specs or just use some more self-descriptive and unified terms? For example, | "roid" or "domainID" for naming the ID of domain object, which one is | better? | 2) Is the extension interface necessary or not? -- David Collier-Brown Director of Engineering Migration and Consolidation Zylog Systems (Canada) Ltd. 2 Sheppard Avenue East, Suite 2000, Toronto, ON Canada M2N 5Y7 (416) 225-9900 x4270 | Fax. (416) 225.9104 From fobispo@isc.org Wed Jun 13 22:50:11 2012 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 35E7421F8680 for ; Wed, 13 Jun 2012 22:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0jijlFvbqTR for ; Wed, 13 Jun 2012 22:50:10 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 92AE921F8679 for ; Wed, 13 Jun 2012 22:50:10 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id A40565F989F; Thu, 14 Jun 2012 05:49:55 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from [192.168.255.160] (c-24-7-39-79.hsd1.ca.comcast.net [24.7.39.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C6621216C33; Thu, 14 Jun 2012 05:49:53 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Francisco Obispo In-Reply-To: <4FD63DB0.3030601@zylog.ca> Date: Thu, 14 Jun 2012 05:49:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <68212213-6873-45BA-866F-69BB461DB918@isc.org> References: <4FD63DB0.3030601@zylog.ca> To: david.collier-brown@zylog.ca X-Mailer: Apple Mail (2.1278) Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt (an a test) X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 05:50:11 -0000 "Repository Object Identifier", I guess we could also use: "Object Identifier" or simply "id"=20 On Jun 11, 2012, at 6:49 PM, David Collier-Brown wrote: > As to terms, I find the more self-describing the better, so "roid" = sounds undesirable *unless*=20 > it's a really well-known term of art. >=20 > This is also a test to see if the list is down or just quiet (;-)) >=20 > --dave >=20 > Ning Kong wrote: > | This is a 00 draft to describe a response format in JSON for name > | registries. This document has been reviewed and improved by the = design team. > | The following issues are still needed to be further discussed. > | 1) As for the naming of the terms, should we try to follow the = EPP > | specs or just use some more self-descriptive and unified terms? For = example, > | "roid" or "domainID" for naming the ID of domain object, which one = is > | better? > | 2) Is the extension interface necessary or not? >=20 >=20 > --=20 > David Collier-Brown > Director of Engineering > Migration and Consolidation > Zylog Systems (Canada) Ltd. > 2 Sheppard Avenue East, Suite 2000, Toronto, ON Canada M2N 5Y7 > (416) 225-9900 x4270 | Fax. (416) 225.9104=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds Francisco Obispo=20 email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From superuser@gmail.com Wed Jun 13 22:51:17 2012 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 4988021F8683 for ; Wed, 13 Jun 2012 22:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CToFVKT1ihCE for ; Wed, 13 Jun 2012 22:51:15 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEA121F8679 for ; Wed, 13 Jun 2012 22:51:15 -0700 (PDT) Received: by lagv3 with SMTP id v3so1020918lag.31 for ; Wed, 13 Jun 2012 22:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R7Z+yUK9YW/o1vQfZVpenohgORE3B/aiPGHJt/dlH90=; b=yu/obw8LZY7v+wf5jNh4EV6Xq3HIw88DEAEu2Ceo3OpurJ36sPl8sES5pHzRdbR8UK IhzpNaRY52fV0K5BOwuQQlYlUb0PioaIufN4MdrxHbuHj2H/egMdfTX6Ax81rgnbexHS YRvrb706suv/3wIzVrvrZb0LOlYhvm6VbW7lJ9zuBm2c1YfmfveXFaJL/bs/XLmz7vrz BvEnhByRfwogOJNrSs3cShbKs+x9Iy7OeQVcX0gzZwnrb2JV6x4327l38dpVMB7pGUxQ P7z9jLLh3QhoRCR359UuhWgVQrLQBX7oELOlbargkdWfV7nXt3b8FdUHIc39Icj8RZYu jSWA== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr452005lbn.10.1339653074362; Wed, 13 Jun 2012 22:51:14 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 13 Jun 2012 22:51:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Jun 2012 22:51:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Bob Bruen Content-Type: multipart/alternative; boundary=bcaec554d63c9ea1f804c26849fd Cc: weirds@ietf.org Subject: Re: [weirds] lessons learned X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 05:51:17 -0000 --bcaec554d63c9ea1f804c26849fd Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 13, 2012 at 6:19 AM, Bob Bruen wrote: > This is been a learning experience for me. I have been around for a long > time and it appears I missed some important changes. I was working under > the old IETF model, where if you showed up, you were part of the process. > The important thing was to get it right. It was a thoughtful time. > > Now, it seems that the agenda of special interest groups run the process. > I am not part of "the community" because I am considered a "data consumer" > and in this case the "data providers" are running the show. The agenda has > been set. Now it just gets implemented. > > Speaking as a co-chair (and I imagine Olaf agrees, though I have not checked with him about this reply), I fully expect this working group to be equally considerate of the concerns of both producers and consumers in this work. Speaking as a participant, I consider myself a data consumer, and so what I contribute to this group will come primarily from that perspective. I'm behind on recent threads, but I'm a little alarmed that your recent experience has led you to the conclusion you gave above. It's certainly not where I want this group to be. -MSK --bcaec554d63c9ea1f804c26849fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 13, 2012 at 6:19 AM, Bob Bruen <bob@coldrain.net>= wrote:
This is been a learning experience for me. I have been around for a long ti= me and it appears I missed some important changes. I was working under the = old IETF model, where if you showed up, you were part of the process. The i= mportant thing was to get it right. It was a thoughtful time.

Now, it seems that the agenda of special interest groups run the process. I= am not part of "the community" because I am considered a "d= ata consumer" and in this case the "data providers" are runn= ing the show. The agenda has been set. Now it just gets implemented.


Speaking as a co-chair (and I imagine Olaf agrees= , though I have not checked with him about this reply), I fully expect this= working group to be equally considerate of the concerns of both producers = and consumers in this work.

Speaking as a participant, I consider myself a data consumer, and so wh= at I contribute to this group will come primarily from that perspective.

I'm behind on recent threads, but I'm a little ala= rmed that your recent experience has led you to the conclusion you gave abo= ve.=A0 It's certainly not where I want this group to be.

-MSK
--bcaec554d63c9ea1f804c26849fd-- From superuser@gmail.com Wed Jun 13 23:14:35 2012 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 F067F21F8595 for ; Wed, 13 Jun 2012 23:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.32 X-Spam-Level: X-Spam-Status: No, score=-3.32 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfYyq8Hs2AnO for ; Wed, 13 Jun 2012 23:14:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CABD121F8593 for ; Wed, 13 Jun 2012 23:14:33 -0700 (PDT) Received: by lagv3 with SMTP id v3so1032582lag.31 for ; Wed, 13 Jun 2012 23:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fNZ2KXslU5Z0pKbMTT/APyxhB/WskVWqgvVsX86N3iA=; b=YqEI1BWQoV78WH3wX7Yjc+5jhH7JAnYA0wlFa2hQC4sLpfyNWoqe3jWWEEAILTupyC 34or6uLafLqJBkTub7tIldwdLOVi5XwFfbcvnErwRN7sGwvPbtlpV7ybMBpWG+ObA1s7 R3CNPFi/GpfDxZU9mqPAAbzDmgLqX9Uqbx9/hvmuMxwqgYkPqaiYwUFd7Dn7aYKYCJ7X JL3nNKDEWWg2/nbJ/jKAs+r35OqWBFIN3n0LuotCHkz2XDrQjohs2HpPAvLxuFG2ubjL ekvqYcIgjjcfLkWJWMmsL5bjsqmWKKO52iy7yqWlHUUT+h9fHi7TtO80LP1Vd5Rc4PkJ Hu2w== MIME-Version: 1.0 Received: by 10.152.148.199 with SMTP id tu7mr577702lab.43.1339654472815; Wed, 13 Jun 2012 23:14:32 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Wed, 13 Jun 2012 23:14:32 -0700 (PDT) In-Reply-To: <20120612193505.GL25201@mail.yitter.info> References: <20120612193505.GL25201@mail.yitter.info> Date: Wed, 13 Jun 2012 23:14:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=e89a8f2353bbf9532d04c2689c94 Cc: weirds@ietf.org Subject: Re: [weirds] policy & tech X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 06:14:35 -0000 --e89a8f2353bbf9532d04c2689c94 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jun 12, 2012 at 12:35 PM, Andrew Sullivan w= rote: > The claims included the following (from the charter): > > The WHOIS protocol does not offer any differential service; it > cannot differentiate among clients to offer different subsets of > information or to allow different access rates to it. > > [=85] > > and may use > standard features of HTTP to support differential service levels > to different classes of user. > > I will object, very strongly, if this WG produces things that do not > possibly provide such differentiation. I leave to the chairs the > determination of whether further discussion of this question is > on-topic for the list, but I don't have more to say on the topic. > > Differential service was indeed identified as a desirable thing by both sides (names and numbers) during the chartering process. I concur with Andrew's position that enabling policy is not identical to creating or enforcing policy. If we produce something that is capable of both class-of-service mode and port-43-clone mode, I'd say we've done the right thing. Perhaps to allay some of Bob's concerns, you might actually find that you benefit from some kinds of differential service. A spam filtering agent (just ti pick a wild example) might be delighted to give up access to complete registered objects, accepting only a few key fields, in exchange for a far higher query limit. That sort of tradeoff isn't possible without a protocol that enables some kind of differential service. Perhaps most importantly, however: Andrew's correct in pointing out that we chartered to include that in our output, and so debating that point is indeed off-topic unless someone wants to propose a charter change already. -MSK, as co-chair --e89a8f2353bbf9532d04c2689c94 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jun 12, 2012 at 12:35 PM, Andrew Sullivan <ajs@anvilwalrusden= .com> wrote:
The claims included the following (from the charter):

=A0The WHOIS protocol does not offer any differential service; it
=A0cannot differentiate among clients to offer different subsets of
=A0information or to allow different access rates to it.

[=85]

=A0 =A0and may use
=A0standard features of HTTP to support differential service levels
=A0to different classes of user.

I will object, very strongly, if this WG produces things that do not
possibly provide such differentiation. =A0I leave to the chairs the
determination of whether further discussion of this question is
on-topic for the list, but I don't have more to say on the topic.


Differential servi= ce was indeed identified as a desirable thing by both sides (names and numb= ers) during the chartering process.=A0 I concur with Andrew's position = that enabling policy is not identical to creating or enforcing policy.=A0 I= f we produce something that is capable of both class-of-service mode and po= rt-43-clone mode, I'd say we've done the right thing.

Perhaps to allay some of Bob's concerns, you might actually find th= at you benefit from some kinds of differential service.=A0 A spam filtering= agent (just ti pick a wild example) might be delighted to give up access t= o complete registered objects, accepting only a few key fields, in exchange= for a far higher query limit.=A0 That sort of tradeoff isn't possible = without a protocol that enables some kind of differential service.

Perhaps most importantly, however: Andrew's correct in pointing out= that we chartered to include that in our output, and so debating that poin= t is indeed off-topic unless someone wants to propose a charter change alre= ady.

-MSK, as co-chair

--e89a8f2353bbf9532d04c2689c94-- From ebw@abenaki.wabanaki.net Thu Jun 14 07:39:44 2012 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 950A121F86A8 for ; Thu, 14 Jun 2012 07:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9uoc0yucj3P for ; Thu, 14 Jun 2012 07:39:44 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id EFF5221F8671 for ; Thu, 14 Jun 2012 07:39:43 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5EBVjDQ076183 for ; Thu, 14 Jun 2012 07:31:46 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FD9F7A8.1010500@abenaki.wabanaki.net> Date: Thu, 14 Jun 2012 10:39:36 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "weirds@ietf.org >> \"weirds@ietf.org\"" References: <4FD8DB8F.2050304@abenaki.wabanaki.net> In-Reply-To: <4FD8DB8F.2050304@abenaki.wabanaki.net> X-Forwarded-Message-Id: <4FD8DB8F.2050304@abenaki.wabanaki.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [weirds] Fwd: Re: lessons learned X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 14:39:44 -0000 this appears to have gotten stuck somewhere. -------- Original Message -------- Subject: Re: [weirds] lessons learned Date: Wed, 13 Jun 2012 14:27:27 -0400 From: Eric Brunner-Williams Reply-To: ebw@abenaki.wabanaki.net Organization: wampumpeag To: weirds@ietf.org On 6/13/12 11:58 AM, John Levine wrote: > I'm sorry, but this totally misunderstands what standards are and what > they can do. this overlooks what the process itself does, which, inter alia, is to remove the anti-trust liability of the contributors' employers for what is frequently a "raising of the bar". not likely to interest those with a single use case, whether "licit" data miners or "illicit" data miners, operating externally to any particular contractual regime, but something of interest to those who ... contrive with competitors. All an IETF standard can do is tell people how to > interoperate if they are already inclined to do so. this is all a specification can provide any implementer or service provider attempting to produce, or consume -- a specified semantic and associated syntax. > Much though I would like to say the servers MUST answer all queries > without ... the problem is simplified if one assumes facts no longer (for quite some time) in evidence, e.g., the non-existence of bad actors. > There are other places to have policy arguments. This isn't one. the "policy" argued reduces to someone has the only use case that matters, according to that someone. not the first time that claim has been made. tedious. boring. wrong. etc. -e From vesely@tana.it Thu Jun 14 11:33:22 2012 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 378C521F86F9 for ; Thu, 14 Jun 2012 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 K5e8jsYD4fD4 for ; Thu, 14 Jun 2012 11:33:21 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 892C121F8668 for ; Thu, 14 Jun 2012 11:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1339698790; bh=fFZSN7AwODD0xLr212SpewRUdYrMdkoQffVYM7xLdZM=; l=757; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ROHGY5+SBsC9fR0On1lG+QWrH+wiuvQQRLf91SmsGXZHs23V6DUP0k9D73CdnhTLY 0ClUrtHMOlM+mESXZuduOdmEiv6ABGUI5VIhOW/Jdtp7ZXqPAp4LIBbhbUFD9CAhnU /cgb2TAj41ASGda9vWkPSylbFt/JXdJIVF17IziY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 14 Jun 2012 20:33:10 +0200 id 00000000005DC033.000000004FDA2E66.00002CF6 Message-ID: <4FDA2E65.9080000@tana.it> Date: Thu, 14 Jun 2012 20:33:09 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 18:33:22 -0000 On Tue 12/Jun/2012 19:17:10 +0200 Bob Bruen wrote: > > Murray and John and some LE folks may be willing to trade off, but > a lot of us are not. I also think there is a difference between > individuals and businesses - if you to differentiate a service > level, this could be one. LE and gov (especially for CCTLDs) agencies would be better qualifiers than business/ individual --what business? CAs are a business that should qualify for such differentiation, whether they have a VAT number or not. How do WHOIS providers currently manage group authorizations? Will the 1.For-all-implementers structure that Olaf mentioned in http://www.ietf.org/mail-archive/web/weirds/current/msg01131.html also define an auth layer, OAuth or similar? From bob@coldrain.net Thu Jun 14 12:13:54 2012 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 4E2C321F8775 for ; Thu, 14 Jun 2012 12:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.148 X-Spam-Level: X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWsrj1kNQ0Aj for ; Thu, 14 Jun 2012 12:13:53 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id 58B4F21F865B for ; Thu, 14 Jun 2012 12:13:53 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5EJDoIZ011464; Thu, 14 Jun 2012 15:13:50 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5EJDotw011461; Thu, 14 Jun 2012 15:13:50 -0400 Date: Thu, 14 Jun 2012 15:13:50 -0400 (EDT) From: Bob Bruen To: Alessandro Vesely In-Reply-To: <4FDA2E65.9080000@tana.it> Message-ID: References: <4FDA2E65.9080000@tana.it> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 19:13:54 -0000 Hi Alessandro, This is just my opinon: The difference is between individuals, protected by EU privacy rules (and should be protected in other countries), and organizations that make money, not privacy protected. Spammers and other criminals make money, thus should not have their whois information protected from public access, any more than a business selling grapefruit. --bob On Thu, 14 Jun 2012, Alessandro Vesely wrote: > On Tue 12/Jun/2012 19:17:10 +0200 Bob Bruen wrote: >> >> Murray and John and some LE folks may be willing to trade off, but >> a lot of us are not. I also think there is a difference between >> individuals and businesses - if you to differentiate a service >> level, this could be one. > > LE and gov (especially for CCTLDs) agencies would be better qualifiers > than business/ individual --what business? CAs are a business that > should qualify for such differentiation, whether they have a VAT > number or not. > > How do WHOIS providers currently manage group authorizations? > > Will the 1.For-all-implementers structure that Olaf mentioned in > http://www.ietf.org/mail-archive/web/weirds/current/msg01131.html > also define an auth layer, OAuth or similar? > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From michele@blacknight.ie Thu Jun 14 12:20:41 2012 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 B30CC21F8786 for ; Thu, 14 Jun 2012 12:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FROM_NONAME=1.294] 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 7SejJMOJAqbi for ; Thu, 14 Jun 2012 12:20:40 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 8204F21F878B for ; Thu, 14 Jun 2012 12:20:39 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::d4d7:819a:4fb5:c923]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0309.002; Thu, 14 Jun 2012 20:20:38 +0100 From: "\"Michele Neylon :: Blacknight\"" To: Bob Bruen Thread-Topic: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt Thread-Index: AQHNSL8zK9xKwykB9g8h5PS1Ivn8ipb6FgmAgAALXQCAAAHkAA== Date: Thu, 14 Jun 2012 19:20:37 +0000 Message-ID: <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> References: <4FDA2E65.9080000@tana.it> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.101.219.118] Content-Type: text/plain; charset="us-ascii" Content-ID: <9E32EBE8EFE16D479818E9C91DDA0C6A@blacknight.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Alessandro Vesely Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 19:20:41 -0000 On 14 Jun 2012, at 20:13, Bob Bruen wrote: >=20 > Hi Alessandro, >=20 > This is just my opinon: >=20 > The difference is between individuals, protected by EU privacy rules (and= should be protected in other countries), and organizations that make money= , not privacy protected. Spammers and other criminals make money, thus shou= ld not have their whois information protected from public access, any more = than a business selling grapefruit. And I'd actually agree with that (personally), though the privacy debate is= probably way off topic here :)=20 Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From ebw@abenaki.wabanaki.net Thu Jun 14 13:00:15 2012 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 084DC21F86D4 for ; Thu, 14 Jun 2012 13:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX5BuxKJvDGN for ; Thu, 14 Jun 2012 13:00:14 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7AF21F86BD for ; Thu, 14 Jun 2012 13:00:13 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5EGqC4v077202 for ; Thu, 14 Jun 2012 12:52:13 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FDA42C6.1060808@abenaki.wabanaki.net> Date: Thu, 14 Jun 2012 16:00:06 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> In-Reply-To: <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:00:15 -0000 On 6/14/12 3:20 PM, "Michele Neylon :: Blacknight" wrote: >> > The difference is between individuals, protected by EU privacy rules (and should be protected in other countries), and organizations that make money, not privacy protected. Spammers and other criminals make money, thus should not have their whois information protected from public access, any more than a business selling grapefruit. at first glance this appears to be an add to the data model, inserting the unfortunate epp binary publish/don't-publish toggle into the data at the registrant, natural person / legal person indicator. of course, that indicator doesn't exist or is inferred heuristically, making automated processing problematic. to add to the complexity, there is the for-profit (and profitable) vs non-profit ... work on the p3p spec was illuminating. the treaty of europe is cognizant of past harms to religious and ethnic social identities and the data protection directive attempts to prevent these harms by preventing targeting religious and ethnic social identities. it is a stretch to think the protection is restricted to individuals, not to associations of individuals, such as synagog members and rom speakers. > And I'd actually agree with that (personally), though the privacy debate is probably way off topic here :) its not so much a "privacy debate" as it is an vague and probably quite difficult data model proposal. -e From michele@blacknight.ie Thu Jun 14 13:32:57 2012 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 3790D21F85A1 for ; Thu, 14 Jun 2012 13:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FROM_NONAME=1.294] 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 BBOmISY+lfXG for ; Thu, 14 Jun 2012 13:32:56 -0700 (PDT) Received: from exchange.blacknight.ie (exchange.blacknight.ie [81.17.243.252]) by ietfa.amsl.com (Postfix) with ESMTP id 224E621F856C for ; Thu, 14 Jun 2012 13:32:55 -0700 (PDT) Received: from bkexchmbx02.blacknight.local ([fe80::d4d7:819a:4fb5:c923]) by bkexchhubcas01.blacknight.local ([fe80::3ca9:6bf1:bd5d:24b%15]) with mapi id 14.02.0309.002; Thu, 14 Jun 2012 21:32:54 +0100 From: "\"Michele Neylon :: Blacknight\"" To: "" Thread-Topic: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt Thread-Index: AQHNSmzgzG/h+UlxTU2NIsx3JTTOtA== Date: Thu, 14 Jun 2012 20:32:54 +0000 Message-ID: <4F2538C315ACAC42AD334C533C247C47565BE593@bkexchmbx02.blacknight.local> References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDA42C6.1060808@abenaki.wabanaki.net> In-Reply-To: <4FDA42C6.1060808@abenaki.wabanaki.net> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.101.219.118] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:32:57 -0000 On 14 Jun 2012, at 21:00, Eric Brunner-Williams wrote: > On 6/14/12 3:20 PM, "Michele Neylon :: Blacknight" wrote: >>>> The difference is between individuals, protected by EU privacy rules (= and should be protected in other countries), and organizations that make mo= ney, not privacy protected. Spammers and other criminals make money, thus s= hould not have their whois information protected from public access, any mo= re than a business selling grapefruit. >=20 > at first glance this appears to be an add to the data model, inserting > the unfortunate epp binary publish/don't-publish toggle into the data > at the registrant, natural person / legal person indicator. >=20 > of course, that indicator doesn't exist or is inferred heuristically, > making automated processing problematic. >=20 > to add to the complexity, there is the for-profit (and profitable) vs > non-profit ... >=20 > work on the p3p spec was illuminating. the treaty of europe is > cognizant of past harms to religious and ethnic social identities and > the data protection directive attempts to prevent these harms by > preventing targeting religious and ethnic social identities. it is a > stretch to think the protection is restricted to individuals, not to > associations of individuals, such as synagog members and rom speakers. >=20 >> And I'd actually agree with that (personally), though the privacy debate= is probably way off topic here :)=20 >=20 > its not so much a "privacy debate" as it is an vague and probably > quite difficult data model proposal. Agreed. -- Mr Michele Neylon Blacknight Solutions Hosting & Colocation, Brand Protection http://www.blacknight.com/ http://blog.blacknight.com/ http://mneylon.tel/ Intl. +353 (0) 59 9183072 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 1 4811 763 Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From AMaitland@Commerco.Com Thu Jun 14 20:57:29 2012 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 3FD4611E80C5 for ; Thu, 14 Jun 2012 20:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_46=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 zPjChL+d+S2U for ; Thu, 14 Jun 2012 20:57:28 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5BA11E80B6 for ; Thu, 14 Jun 2012 20:57:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=R8JL6DewlNoITSZmFKjHUhbuuNcl0fptbEgO/l1NxwdDWrQ4+dnqDHimb6Ep6fcTHotbw3Wu5ob59l935/fSfMsEEjLQACgU/RtA4MkjjJkjArqZEGZe8LBk+61wa16dpV6iFUkDwqNzJzUp5ABcMosY7WT3GIxZOcpb40GQ0iA= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 15 Jun 2012 03:57:25 +0000 Message-ID: <4FDAB29F.1090303@Commerco.Com> Date: Thu, 14 Jun 2012 21:57:19 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> In-Reply-To: <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 03:57:29 -0000 Respectfully, privacy is very important as it relates to design considerations and discussions for what is and what may not be releasable information from the registries and how that information may be switched on or off at the registries for each other or public data consumers. I absolutely agree with Bob on his point. Logically, I cannot think of any reason that a commercial business should ever be entitled to privacy in the sense of being able not being able locate and identify the business - especially so when that "business" reaches out to touch my own business or those of my clients in a less than neighborly way. Alan Maitland On 6/14/2012 1:20 PM, "Michele Neylon :: Blacknight" wrote: > > On 14 Jun 2012, at 20:13, Bob Bruen wrote: > >> >> Hi Alessandro, >> >> This is just my opinon: >> >> The difference is between individuals, protected by EU privacy rules (and should be protected in other countries), and organizations that make money, not privacy protected. Spammers and other criminals make money, thus should not have their whois information protected from public access, any more than a business selling grapefruit. > > > And I'd actually agree with that (personally), though the privacy debate is probably way off topic here :) > > Regards > > Michele > -- > Mr Michele Neylon > Blacknight Solutions > Hosting& Colocation, Brand Protection > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://mneylon.tel/ > Intl. +353 (0) 59 9183072 > Locall: 1850 929 929 > Direct Dial: +353 (0)59 9183090 > Fax. +353 (0) 1 4811 763 > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > From ebw@abenaki.wabanaki.net Thu Jun 14 21:11:53 2012 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 3348F11E80BE for ; Thu, 14 Jun 2012 21:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 wENDNBSh8Ax8 for ; Thu, 14 Jun 2012 21:11:52 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 9046211E80B6 for ; Thu, 14 Jun 2012 21:11:52 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5F13lmL078937 for ; Thu, 14 Jun 2012 21:03:47 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FDAB602.1000709@abenaki.wabanaki.net> Date: Fri, 15 Jun 2012 00:11:46 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> In-Reply-To: <4FDAB29F.1090303@Commerco.Com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 04:11:53 -0000 On 6/14/12 11:57 PM, Alan Maitland wrote: > Respectfully, privacy is very important ... and you're the first person to ever think of that. > Logically, I cannot think of any reason that a commercial business ... and how, mr. spock, do you propose to distinguish "commercial business" {numbers,names} registrants from any other registrants? -e From ajs@anvilwalrusden.com Thu Jun 14 21:20:59 2012 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 1024D11E80B6 for ; Thu, 14 Jun 2012 21:20:59 -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 ZqCafSd7+YNC for ; Thu, 14 Jun 2012 21:20:58 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id EE52E11E80B3 for ; Thu, 14 Jun 2012 21:20:57 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 222CB1ECB41C for ; Fri, 15 Jun 2012 04:20:57 +0000 (UTC) Date: Fri, 15 Jun 2012 00:16:28 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120615041628.GA29478@mail.yitter.info> References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FDAB29F.1090303@Commerco.Com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 04:20:59 -0000 On Thu, Jun 14, 2012 at 09:57:19PM -0600, Alan Maitland wrote: > I absolutely agree with Bob on his point. Logically, I cannot think > of any reason that a commercial business should ever be entitled to > privacy in the sense of being able not being able locate and None of that is relevant to this question. Whether something is a particular policy that we think ought to be implemented in some particular case is not the question; the question is, does the protocol need to accommodate the use case under some circumstances? We have at least one use case ("ordinary schlub who has registered a domain name for other than commercial purposes") where it seems important to be able to make distinctions between completely anonymous access to that data, and access to that data when the requester has been authenticated and is authorized to collect the data. If there is reason to believe that the use case is one we should worry about (and I think there is such a reason), then we need that mechanism in the protocol. How that mechanism gets used in the future is not our job to decide. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From johnl@iecc.com Thu Jun 14 21:41:08 2012 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 3987C11E80BE for ; Thu, 14 Jun 2012 21:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGizx3xLtiev for ; Thu, 14 Jun 2012 21:41:06 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1C58711E80B3 for ; Thu, 14 Jun 2012 21:41:05 -0700 (PDT) Received: (qmail 42821 invoked from network); 15 Jun 2012 04:41:04 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Jun 2012 04:41:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fdabce0.xn--yuvv84g.k1206; i=johnl@user.iecc.com; bh=eDpDgaE3Id6ULfrc2zuA9Cg2MQglaFRwU9DgVxCq1CU=; b=kIx4myHrmlAuKxpdY5rYaQMefN4EHTSZT6VvcIZMR+leyUqgVPwwBiVOfjqe6MkGZnoBrHVu+HLBUDf7T+6rALFi3BLEXsiRi/NTKwe3ZUg0IRg6FycxP3G6XLE7uNKm33a4ktZWKz3h9gvdxGtvCi7msv5m+GZof+O1ajcrRSA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 15 Jun 2012 04:40:41 -0000 Message-ID: <20120615044041.90927.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <4FDAB602.1000709@abenaki.wabanaki.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 04:41:08 -0000 >and how, mr. spock, do you propose to distinguish "commercial >business" {numbers,names} registrants from any other registrants? Seems like an ideal application for RFC 3514. R's, John From AMaitland@Commerco.Com Thu Jun 14 21:45:10 2012 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 6596311E80C2 for ; Thu, 14 Jun 2012 21:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 tLvzwWFTc752 for ; Thu, 14 Jun 2012 21:45:09 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5817E11E80B3 for ; Thu, 14 Jun 2012 21:45:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=ppqhJ7aukUr6Lj5vMQCyQNIcvn6rrba/Qgw72s5fDKhwlpsPBscxSLi4tbTBS01zj7H9eMyo6wqi5y/OyifI8bm4Ti+Up9ZFiCf5QDQp9D0h4U6CcGSAGkWlqXJFWQTCPFS0UiV6Q8Sm9Pa7xdyg78OD0BROZUwxOpo9WCsaVAo= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 15 Jun 2012 04:45:04 +0000 Message-ID: <4FDABDCA.9020909@Commerco.Com> Date: Thu, 14 Jun 2012 22:44:58 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> <4FDAB602.1000709@abenaki.wabanaki.net> In-Reply-To: <4FDAB602.1000709@abenaki.wabanaki.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 04:45:10 -0000 On 6/14/2012 10:11 PM, Eric Brunner-Williams wrote: > On 6/14/12 11:57 PM, Alan Maitland wrote: >> Respectfully, privacy is very important ... > > and you're the first person to ever think of that. Taking a list member's statement out of context for effect is arguably a cheap shot. The original poster appeared to think that privacy was not relevant to the discussion at hand. I disagreed as regards design considerations and discussions focused on the WIERDS specification. > >> Logically, I cannot think of any reason that a commercial business ... > > and how, mr. spock, do you propose to distinguish "commercial > business" {numbers,names} registrants from any other registrants? It does not take much to actually ask in the registrant's registry application for {names,numbers}. Also logically, it would make sense to have a penalty associated with providing a provably invalid or inaccurate response. That said, this is the kind of thing is something for the registries to determine how they would like to implement or not. The point is that the specification must be flexible enough to address the need. > > -e > Alan From AMaitland@Commerco.Com Thu Jun 14 22:01:22 2012 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 730C621F8567 for ; Thu, 14 Jun 2012 22:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 SVCCAybwL0aO for ; Thu, 14 Jun 2012 22:01:21 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 668A821F8564 for ; Thu, 14 Jun 2012 22:01:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=wrT0Bxi1trVC9UQVp/2/9Q03Vt0GPeV0zu7nYuVZpr20qHnPNRcwazVwb3iGtzaD9IQUbbNd6JyTXzkP4tO39oLHtDcmNe3PL9eg8f2UYVVSMpW/7tP5V3YKq2pNwOWdMYovFE4tj8OWduj43D6VqqLu15LBrKZnKY5IS5HdL2c= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 15 Jun 2012 05:01:13 +0000 Message-ID: <4FDAC193.3020608@Commerco.Com> Date: Thu, 14 Jun 2012 23:01:07 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> <20120615041628.GA29478@mail.yitter.info> In-Reply-To: <20120615041628.GA29478@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 05:01:22 -0000 On 6/14/2012 10:16 PM, Andrew Sullivan wrote: > On Thu, Jun 14, 2012 at 09:57:19PM -0600, Alan Maitland wrote: > >> I absolutely agree with Bob on his point. Logically, I cannot think >> of any reason that a commercial business should ever be entitled to >> privacy in the sense of being able not being able locate and > > None of that is relevant to this question. Whether something is a > particular policy that we think ought to be implemented in some > particular case is not the question; the question is, does the > protocol need to accommodate the use case under some circumstances? Your point is well taken. > > We have at least one use case ("ordinary schlub who has registered a > domain name for other than commercial purposes") where it seems > important to be able to make distinctions between completely anonymous > access to that data, and access to that data when the requester has > been authenticated and is authorized to collect the data. If there is > reason to believe that the use case is one we should worry about (and > I think there is such a reason), then we need that mechanism in the > protocol. How that mechanism gets used in the future is not our job > to decide. Agreed. The Internet has changed remarkably over the past 20 years and some of the issues we have today were apparently not seen or not considered worthy of addressing (for whatever reasons) in the days of some of the earlier RFCs. Hopefully many who develop specification documents would agree that it seems misguided to develop a specification designed to address a need without considering the environment in which the specification addressing the need will reside. Perhaps this might be why you think that there is a reason to add a mechanism for authentication of the requester and authorization to use specific data in part or in total - that kind of thinking in the specification design allows the actual implementers of the specification more choice and flexibility in their implementations while maintaining interoperability... which is almost always a good thing. > > Best, > > A > Alan From AMaitland@Commerco.Com Thu Jun 14 22:09:29 2012 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 48A2021F8595 for ; Thu, 14 Jun 2012 22:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 hxpypsNKSo4c for ; Thu, 14 Jun 2012 22:09:28 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4563F21F857D for ; Thu, 14 Jun 2012 22:09:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=l/HUcjeZKUmQsgDA5fZeF4n6nehhAPhCg5ZWAipXWI0pnoKsz4fThmgQ9m7Fn+l3xhZRlcpQsrSfeY/y9wtEyXEcio6c6x+5INlgzQ9R3bvPOrjtAQiJZRzzGKGacwQuQ2sgWvjnMiWsTUEN+l69g6h9jlScoJz9xXHjkP9lR4Q= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 15 Jun 2012 05:09:27 +0000 Message-ID: <4FDAC386.3050201@Commerco.Com> Date: Thu, 14 Jun 2012 23:09:26 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: weirds@ietf.org References: <20120615044041.90927.qmail@joyce.lan> In-Reply-To: <20120615044041.90927.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 05:09:29 -0000 On 6/14/2012 10:40 PM, John Levine wrote: >> and how, mr. spock, do you propose to distinguish "commercial >> business" {numbers,names} registrants from any other registrants? > > Seems like an ideal application for RFC 3514. > > R's, > John Of course... along with the ultimate sure fire application solution which solves all security problems... What was that acronym used a lot in a list working to address email "issues"? Thought you may have coined it... Thank you for improving the mood, really quite a fun RFC to read - date noted. Alan From sm@resistor.net Thu Jun 14 23:47:03 2012 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 77DB521F8483 for ; Thu, 14 Jun 2012 23:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Q4dbygVIm5Ex for ; Thu, 14 Jun 2012 23:47:01 -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 3D88421F8480 for ; Thu, 14 Jun 2012 23:47:01 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5F6kPGh028753; Thu, 14 Jun 2012 23:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339742789; i=@resistor.net; bh=P26KA898e1jKnw6DIE4ZDmpg4RI4IP+n7v2Rgd/9om0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=dD8DdNHwT7xA2i+mCls8oDg5HYNuJmweFCdwF2Z3L2QHwI5pfWablvbsk91bNQFw7 h9bEbyt/9qxIthIE19F6NMU2tGXeT22THOmHDY+JmM/gJSFNneNMgvaO9EDi3ERGNs 2fjrzrWpKXh+SbDyVhZUauR5VKby9KkPhlq6+U8A= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339742789; i=@resistor.net; bh=P26KA898e1jKnw6DIE4ZDmpg4RI4IP+n7v2Rgd/9om0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JnxGq4SoIJh2o13C4FDJB0bxejy9mQWc3k5S2GkSnzrRRTbSDaie9dSdqXfBKq7DA 91ose+kA8mB6Yg1M0cYEi9nAMl+D83NdAzLKohHpcQKIl2BFQN2KPMr9BRTto6wRNV I/exCZkvA23GPRiy0HRTxoCUNpmDaow4Rj5oAAKQ= Message-Id: <6.2.5.6.2.20120614220339.09377f10@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 14 Jun 2012 23:44:47 -0700 To: Alan Maitland From: SM In-Reply-To: <4FDAC193.3020608@Commerco.Com> References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> <20120615041628.GA29478@mail.yitter.info> <4FDAC193.3020608@Commerco.Com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 06:47:03 -0000 Hi Alan, At 22:01 14-06-2012, Alan Maitland wrote: >Agreed. The Internet has changed remarkably over the past 20 years >and some of the issues we have today were apparently not seen or not >considered worthy of addressing (for whatever reasons) in the days >of some of the earlier RFCs. Some of the issues seen today can be traced back to the past. There are two words in draft-kucherawy-weirds-requirements-04 which may be of interest. Regards, -sm From superuser@gmail.com Thu Jun 14 23:47:46 2012 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 58B4D21F8483 for ; Thu, 14 Jun 2012 23:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J34LtHsvi9m for ; Thu, 14 Jun 2012 23:47:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5373B21F848A for ; Thu, 14 Jun 2012 23:47:45 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so2956535lbb.31 for ; Thu, 14 Jun 2012 23:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=igH8MtRPhhVNZ9FSukkU+xoPOhqSft9hbpZ4OHozt2U=; b=lDp89Y1ZwTscLtcLK/QjstKPlSnZEAwvlyo+GLkVvGsPiCnqn/TJaN1RfDnMTrn+1q o2oK7Th92J4YwLCEvpjzDhf1OYkA322IN8x2+lbTEJnfuEMh3CrR3/SzNH3M9nHcnwH9 jIqU9oimbxyhnzODuImRuij7d1rcUH0dQofWb1FwWBETAqU3mRwh1elXUerXtYFapMZT aHQDGp6slzG8oB6uBLEqFmyrZpmSBxiZdis5r9FhNdZgVnoZXgpyMV8drZghGLhywATP j3NEleBOam9tiZfqGeFKcfkXr0QI7yArbZp6+/O1H+igI+rq2A6YLcKilXbtHV1O0/OU HIyg== MIME-Version: 1.0 Received: by 10.112.49.100 with SMTP id t4mr2133770lbn.10.1339742864115; Thu, 14 Jun 2012 23:47:44 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Thu, 14 Jun 2012 23:47:44 -0700 (PDT) In-Reply-To: <20120615041628.GA29478@mail.yitter.info> References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> <20120615041628.GA29478@mail.yitter.info> Date: Thu, 14 Jun 2012 23:47:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=bcaec554d63c8189b204c27d31cd Cc: weirds@ietf.org Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 06:47:46 -0000 --bcaec554d63c8189b204c27d31cd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jun 14, 2012 at 9:16 PM, Andrew Sullivan wrote: > None of that is relevant to this question. Whether something is a > particular policy that we think ought to be implemented in some > particular case is not the question; the question is, does the > protocol need to accommodate the use case under some circumstances? > > We have at least one use case ("ordinary schlub who has registered a > domain name for other than commercial purposes") where it seems > important to be able to make distinctions between completely anonymous > access to that data, and access to that data when the requester has > been authenticated and is authorized to collect the data. If there is > reason to believe that the use case is one we should worry about (and > I think there is such a reason), then we need that mechanism in the > protocol. How that mechanism gets used in the future is not our job > to decide. > > > Everything Andrew said is true. But this discussion is likely to reappear as this work reaches an increasingly wider audience. I imagine we would be wise to think about a Privacy Considerations section in some or all of our specification documents, even if only to reflect Andrew's point above. -MSK, participatin' --bcaec554d63c8189b204c27d31cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jun 14, 2012 at 9:16 PM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
None of that is relevant to this question. =A0Whether something is a
particular policy that we think ought to be implemented in some
particular case is not the question; the question is, does the
protocol need to accommodate the use case under some circumstances?

We have at least one use case ("ordinary schlub who has registered a domain name for other than commercial purposes") where it seems
important to be able to make distinctions between completely anonymous
access to that data, and access to that data when the requester has
been authenticated and is authorized to collect the data. =A0If there is reason to believe that the use case is one we should worry about (and
I think there is such a reason), then we need that mechanism in the
protocol. =A0How that mechanism gets used in the future is not our job
to decide.



Everything And= rew said is true.=A0 But this discussion is likely to reappear as this work= reaches an increasingly wider audience.=A0 I imagine we would be wise to t= hink about a Privacy Considerations section in some or all of our specifica= tion documents, even if only to reflect Andrew's point above.

-MSK, participatin'
--bcaec554d63c8189b204c27d31cd-- From vesely@tana.it Fri Jun 15 01:09:10 2012 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 BF37B21F859B for ; Fri, 15 Jun 2012 01:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.237 X-Spam-Level: X-Spam-Status: No, score=-4.237 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 OkNgkGjQBRG6 for ; Fri, 15 Jun 2012 01:09:10 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDD321F85AF for ; Fri, 15 Jun 2012 01:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1339747747; bh=ospiOCo9RFpzbPKySRhdL9xvgP/HEnXu4phtn2H4hQI=; l=1268; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=fintUb1K91zPJNDyu8ls1Sv5V7zK8hXm9T2jPVTHH2Sh12Xkp7VvTN0Ve/IOARODq 7JYnpsljjrCy4/4GL29h/gdYZ26LipgXRpDh6tSPGUDO1t2zCV9608P2xQPFP/fQhz IgSy97GC8YI5pc2eyyU9CJMiHVuc4QwgtdDecKQY= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 15 Jun 2012 10:09:07 +0200 id 00000000005DC035.000000004FDAEDA3.00006383 Message-ID: <4FDAEDA3.1000907@tana.it> Date: Fri, 15 Jun 2012 10:09:07 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDA2E65.9080000@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 08:09:10 -0000 On Thu 14/Jun/2012 21:13:50 +0200 Bob Bruen wrote: > > The difference is between individuals, protected by EU privacy rules > (and should be protected in other countries), and organizations that > make money, not privacy protected. Uh, I thought you were addressing data consumers rather than data subjects. My questions were meant for the former case. > Spammers and other criminals make money, thus should not have their > whois information protected from public access, any more than a > business selling grapefruit. Agreed. IMHO it would be a good idea to discern domains registered for generic publishing purposes from specific categories that deserve special care, such as email and e-commerce. (Enforcement can use outgoing connections to port 25, commerce-enabling certificates, and, of course, the evil bit.) > On Thu, 14 Jun 2012, Alessandro Vesely wrote: >> >> CAs are a business that should qualify for such differentiation, >> whether they have a VAT number or not. >> >> How do WHOIS providers currently manage group authorizations? >> >> Will the 1.For-all-implementers structure that Olaf mentioned in >> http://www.ietf.org/mail-archive/web/weirds/current/msg01131.html >> also define an auth layer, OAuth or similar? From dblumenthal@pir.org Fri Jun 15 05:03:39 2012 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 B31CB21F8619 for ; Fri, 15 Jun 2012 05:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 n5YWELeebrDq for ; Fri, 15 Jun 2012 05:03:39 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com (mail.pir.org [72.44.190.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE1121F8616 for ; Fri, 15 Jun 2012 05:03:38 -0700 (PDT) Received: from PIR-MAIL-01.PIR.com ([192.168.27.12]) by pir-mail-01 ([192.168.27.12]) with mapi; Fri, 15 Jun 2012 08:03:37 -0400 From: Don Blumenthal To: "weirds@ietf.org" Date: Fri, 15 Jun 2012 08:03:35 -0400 Thread-Topic: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt Thread-Index: Ac1K7uTH2q+rZxlCS+q00vcSlaEJoQ== Message-ID: In-Reply-To: <20120615044041.90927.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 12:03:39 -0000 :) I hadn't thought of that in a awhile. Or 1149, although I don't see how it could apply here. On 6/15/12 12:40 AM, "John Levine" wrote: >>and how, mr. spock, do you propose to distinguish "commercial >>business" {numbers,names} registrants from any other registrants? > >Seems like an ideal application for RFC 3514. > >R's, >John >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From olaf@NLnetLabs.nl Fri Jun 15 05:12:15 2012 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 39CD621F858D for ; Fri, 15 Jun 2012 05:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIJEh-IQU+UO for ; Fri, 15 Jun 2012 05:12:14 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B906421F8585 for ; Fri, 15 Jun 2012 05:12:13 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q5FCC8Zo018608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jun 2012 14:12:09 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1339762331; bh=gv8TT/q/l//u8I8cZAdR4lmafnYPrY5HR4DFH2IKNVQ=; h=From:Subject:Date:Cc:To; b=NTBq7yZp4HHGy9ckRUoHKWwVwTtGl6wF3B7tfGgfcSPwSipcKow4dvb+jLarQGp2V mNXZNW7iveTChPQAqzsTGVo/rom0qIRC2GRIug/jrVypCFeLy4Xu+RQedV8tmuZQUh JQ/Ta/Lr/SxiUd4y9rpzmotPlfMY0Z3aMo2quSvI= From: Olaf Kolkman Content-Type: multipart/signed; boundary="Apple-Mail=_A9602853-C25C-42AC-A517-69FAC560054B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Fri, 15 Jun 2012 14:12:04 +0200 Message-Id: To: Web Extensible Internet Registration Data Service Working Group Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 15 Jun 2012 14:12:10 +0200 (CEST) Cc: Pete Resnick Subject: [weirds] For transparency purposes. 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, 15 Jun 2012 12:12:15 -0000 --Apple-Mail=_A9602853-C25C-42AC-A517-69FAC560054B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Colleagues, You may be aware that ICANN put out an RFP for a reference = implementation of a Domain Name Restful Whois Server[1]. You may also be = aware that I am the director of NLnet Labs a non-for profit that = develops Open Source software and Open Standards for the Internet [2]. Today, NLnet Labs submits, in cooperation with SIDN [3], a bid to ICANN. I will oversee the NLnet Labs responsibilities of this work and may be = part of technical discussions but I am not key personnel. My = responsibilities, funding, and commitment towards the WEIRDS WG are = independent of this bid. Since I am co-chairing this group and the relation between the bid and = the WEIRDS charter is evident I feel it is important to be transparent = about the above. Please let me know if you have any questions or = concerns. --Olaf [1] = http://www.icann.org/en/news/announcements/announcement-3-16may12-en.htm [2] See our charter at = http://www.nlnetlabs.nl/labs/about/Statuten-20070322-eng.pdf [3] http://www.sidn.nl/ --Apple-Mail=_A9602853-C25C-42AC-A517-69FAC560054B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJP2yaVAAoJEFRqER47aqpkalUQAJvLuiNZCC94gFH5Is3pariX MpjBm1lx66E5ojCXILar8fqdmwB0LraLdyI0OBvPD5/3s01mCaJYanRRs3tZp5d6 EM1GUWP5gQTwKfCgeAUCwoOENpqxj2Iu4qT7dGHuDAvgnwI8i081fZmDeCHNiqNE l7rXKCsa4uIxaacKR5tDxeV4CqWeiI5LRP5z8aakYIth3N7CMwzVj8xHmtjLQs0C ZCYJkHKGbtiODIocRd3B/dPP+VITCOGCnU1ad274k02OzaPowLtnMXJghguZaCxJ 7pvr9hXpxruYpws53NwAQWlim+5Wke1K6dkGW0TwzISCPYP0H3wMwpWv9c2dQnE/ I6W98N7vbxqkdPzCO5pWGQqQ+lYSUL9pGqluRaz/Du8n9xTu1VQeWHn6ghSSJgnH l2DKVy2HYwpXs1+GI1jvY3HRVaCs8KoQ2NJrOcmLHOq8BzmFogcMznNDgghakg3j NW/fFK77Mh2gJzGoZNlzip5Ihp8E/4OgI7+cZnekj4UhsqHXP0SEXYn9BHVAyLt6 d7J12W7Cm1Btu0hfaz54xU8Ll/3peYoHfYiFGQAtvZoB85I7+ptlj97kwqY81x4o PvNY7zfQDcOUWLtJF4/N9br9SDRVBgnQQcKd9IRwEvdeHS2CMCakT/XwBeDn9OM8 Dgs2e+CR3VNkdDW5C733 =Bk7X -----END PGP SIGNATURE----- --Apple-Mail=_A9602853-C25C-42AC-A517-69FAC560054B-- From andy@hxr.us Fri Jun 15 05:22:36 2012 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 17D8621F861E for ; Fri, 15 Jun 2012 05:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLz5+vUjKv1w for ; Fri, 15 Jun 2012 05:22:35 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE6921F85D8 for ; Fri, 15 Jun 2012 05:22:35 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2446206ghb.31 for ; Fri, 15 Jun 2012 05:22:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ohjKOnRnTQIuHrE1SxwqwB5nblY+5ocO6o7M+u2srZw=; b=TqSSem+GQvwwXyrSbZR2iom+G3KW90pJmpfTgtR3jcGVx7sV5k6tsuIljrFJw8fI0C knQ+lUKANHkiP6GAiSGSUr7g0X1dQB6amUVAvwVHMvRg+WY9TQxIlrPmc4PtjaeAuGpR Xc7F1ONYuGZl2tZAhhA8LwyFWkchKS+Fj0j2b77WFIcUcOEj4pKxPVpg7HnHS6ZoaMaq A9nCiTi7aPlfRERHfBUl8VqDcULKxoabfXO3nRqwZfRnNNNFrk4udIKSb6Yisb8f1eS7 gonJ+K/Era7iyzi+iboHdIYwfZnQ1Joych6UEOasinB4QfbQKzS5uYZehnMak1mcdXjh J28g== Received: by 10.236.76.165 with SMTP id b25mr8009785yhe.0.1339762955182; Fri, 15 Jun 2012 05:22:35 -0700 (PDT) Received: from ?IPv6:2001:500:4:15:6d3d:2dc8:9621:920b? ([2001:500:4:15:6d3d:2dc8:9621:920b]) by mx.google.com with ESMTPS id l13sm15589414ann.2.2012.06.15.05.22.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 05:22:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andy Newton In-Reply-To: Date: Fri, 15 Jun 2012 08:22:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58F25160-28BC-4F35-BE96-5AC22D35BF00@hxr.us> References: To: Olaf Kolkman X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnaP0KYIfNHWfH+bDA2fKeOHFRyM6oSHOyY1BC7AHnHLc972NzGOVJhrS6J8zPIRWXW/Mat Cc: Pete Resnick , Web Extensible Internet Registration Data Service Working Group Subject: Re: [weirds] For transparency purposes. 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, 15 Jun 2012 12:22:36 -0000 Involvement of NLnet Labs and SIDN, especially from an implementation = perspective, is a good thing in my opinion. And I trust Olaf to compartmentalize his roles. Out of curiosity, will either organization be writing client software? -andy= From olaf@NLnetLabs.nl Fri Jun 15 05:25:09 2012 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 36DAA21F863D for ; Fri, 15 Jun 2012 05:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggj9aLwCDUO3 for ; Fri, 15 Jun 2012 05:25:08 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B7521F861E for ; Fri, 15 Jun 2012 05:25:07 -0700 (PDT) Received: from [IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14] ([IPv6:2001:7b8:206:1:ba8d:12ff:fe04:cd14]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q5FCP15W033987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Jun 2012 14:25:02 +0200 (CEST) (envelope-from olaf@NLnetLabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1339763103; bh=v5kL8QwYvArYYXVafEfA949gxtnSgfGRB93ca9oOlkA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=kYwgiHcPoL0LIoURA9VoqWZ5n/635ZFVgcr7g67f5igtRFExsvd5+4fX8J4yFXUBL AfzwqMm7MIbUQcsJvx4rJS5+nntXZNWV6FV3pyxPiqbD4kf5sv2MzMvTgsO0jyjgN8 ZJs0hh0uuKoCAM25WmcW1XlPgVEeJbljqhSaiPhU= Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_89725602-4459-4F9D-BD48-928C037C3B6B"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Olaf Kolkman In-Reply-To: Date: Fri, 15 Jun 2012 14:25:00 +0200 Message-Id: <73F79FA2-0F03-4E10-A507-1E5D70903A3A@NLnetLabs.nl> References: To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]); Fri, 15 Jun 2012 14:25:02 +0200 (CEST) Cc: weirds@ietf.org Subject: Re: [weirds] lessons learned 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, 15 Jun 2012 12:25:09 -0000 --Apple-Mail=_89725602-4459-4F9D-BD48-928C037C3B6B Content-Type: multipart/alternative; boundary="Apple-Mail=_35A90DEA-35E2-4E11-BE57-C610DB8DECC7" --Apple-Mail=_35A90DEA-35E2-4E11-BE57-C610DB8DECC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 14, 2012, at 7:51 AM, Murray S. Kucherawy wrote: >=20 > Speaking as a co-chair (and I imagine Olaf agrees, though I have not = checked with him about this reply), I fully expect this working group to = be equally considerate of the concerns of both producers and consumers = in this work. Olaf agrees... with the qualifier: 'as long those concerns are not about = choosing a particular policy.' I hope we can all keep the following principle in mind: "Design for variation in outcome, so that the outcome can be different = in different places, and the tussle takes place within the design, not = by distorting or violating it. Do not design so as to dictate the = outcome. Rigid designs will be broken; designs that permit variation = will flex under pressure and survive." (=46rom "Tussle in Cyberspace: Defining Tomorrow=92s Internet", Clarke = et al, = http://www.cs.princeton.edu/courses/archive/spr06/cos592/bib/tussle-p347-c= lark.pdf) NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf@NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands --Apple-Mail=_35A90DEA-35E2-4E11-BE57-C610DB8DECC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Speaking = as a co-chair (and I imagine Olaf agrees, though I have not checked with = him about this reply), I fully expect this working group to be equally = considerate of the concerns of both producers and consumers in this = work.

Olaf agrees... with the = qualifier: 'as long those concerns are not about choosing a particular = policy.'

I hope we can all keep the following = principle in mind:

"Design for variation in outcome, so that the outcome can be different in different places, and the tussle takes place within the design, not by distorting or violating it. Do not design so as to dictate the outcome. Rigid designs will be broken; designs that permit variation will flex under pressure and = survive."


(=46rom "Tussle in Cyberspace: Defining = Tomorrow=92s Internet", Clarke et al, http://www.cs.princeton.edu/courses/archive/spr06/cos592= /bib/tussle-p347-clark.pdf)



NLnet
Labs
Olaf M. Kolkman


Science Park 400, 1098 XH Amsterdam, The = Netherlands



= --Apple-Mail=_35A90DEA-35E2-4E11-BE57-C610DB8DECC7-- --Apple-Mail=_89725602-4459-4F9D-BD48-928C037C3B6B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJP2ymcAAoJEFRqER47aqpkshUP/24sTrqxLXyouwXbH/5CXKt/ 6bo65IxU6F6bWM/nJhfqIdCsN+zag2BAAkSOTTtSt1HOKihWxqnY/RiQr61bknw6 J0lgiv+fn/7rTAmpHGu61m05Da2kJuLuDW/mIddq3J86k2OMTlxgytseAEY02nYc xA1umyMmJouRI/CQGu1z7aJ25OiXWO1FjgH4iBrzwOOVsej2qiInI3D4kUq4BBlj 3w0oWwQkaVC2t2qv7iftXHZSEDRgqJq+BGyz9qvQbdQ1pMrJpOiid+H6ggub6ex9 TtNCy3SLoPRpv72vhgELs2ygcwkTWSszZIfM15azf3m30GdKkf7Sm5z7IIFBq+xt BtqhBrETbB2ycVUmVmylOt1uBHacNgM5lLpBeyk/fYbyle5b7svyObizGmz/THCY X+tp841Xjif84gcgElOaS/vUIj5dg0Nn00V3OsLhdfq5afD+/bBTn9dz+ji4pjoz XLwmECGAc8DwLcqjxTMzgG63AF9fp7E8lNJP7p3PScpI3EB+56gf7/XFEhqpUmkP PrsX6KBPiSSbSsJX9hbiR/3NmCn0hJmHAg52T1INrRY+PCLTFmEHg9fce5+ZAWG6 JiMlqpzm7aNUjaGI8EUeya3EVCwzJy5HrpNW9eiCF5Lva0jBa4PE1yFnPz8Ah43/ Ccn+plWIB0Xt8BSxffuk =4gAu -----END PGP SIGNATURE----- --Apple-Mail=_89725602-4459-4F9D-BD48-928C037C3B6B-- From andy@hxr.us Fri Jun 15 05:30:48 2012 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 5044721F8679 for ; Fri, 15 Jun 2012 05:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOfhlGSpNB4L for ; Fri, 15 Jun 2012 05:30:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B734B21F85B6 for ; Fri, 15 Jun 2012 05:30:47 -0700 (PDT) Received: by yenq13 with SMTP id q13so2576251yen.31 for ; Fri, 15 Jun 2012 05:30:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=js/QH6E6SBY8O2ARaYIGYCGYc52J20wT4N+5s0qqQHA=; b=c/dYQtpz6u1qYpJ1JZHxcYDW8FUkbWUntoLH09h027cmiJZ6M0kVgdvJy8JaFXQy4u EMxBYQxHpaUaXhAdDp3rDtwPI1ZE8XaMFqpWzOWz1fRE8Y5U8zxqIoy/Nv37s9M3oIik vrKcBg2WeYeK9kGh3Z+z1OqKQrC/VEg16ST8OsxEv1Y/vQj7rLcHPxixaDfWdkt6Q0md lbrdSI/8Ug3KxlscwIcUAzbGU7HzIuq38+jVNrGQ0MVdOm8UNy2u0rXbWbkRDLTTYGjA 7E0gGSUb7A7EiGg8z47VsaHKvfsAN77LjJBhGZUlITZMfY1j/5dKY7jWi+fdqVqp20Rv XGPw== Received: by 10.236.109.196 with SMTP id s44mr7749456yhg.35.1339763446301; Fri, 15 Jun 2012 05:30:46 -0700 (PDT) Received: from ?IPv6:2001:500:4:15:6d3d:2dc8:9621:920b? ([2001:500:4:15:6d3d:2dc8:9621:920b]) by mx.google.com with ESMTPS id r8sm15606601ani.9.2012.06.15.05.30.44 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 05:30:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Andy Newton In-Reply-To: Date: Fri, 15 Jun 2012 08:30:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> <20120615041628.GA29478@mail.yitter.info> To: Murray S. Kucherawy X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQm4WQfSHEfOsVm6Pw5y6x1A8e9of4idDC6HWeK9lYpkOhp6CikfqHL7kzjvsj36j0cWd5QH Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 12:30:48 -0000 On Jun 15, 2012, at 2:47 AM, Murray S. Kucherawy wrote: > Everything Andrew said is true. But this discussion is likely to = reappear as this work reaches an increasingly wider audience. I imagine = we would be wise to think about a Privacy Considerations section in some = or all of our specification documents, even if only to reflect Andrew's = point above. That would be one long Privacy Considerations section. Perhaps a "Use Cases" draft is appropriate and would focus this = conversation. Andrew has now give 3 use cases, maybe they should be = documented. Also, documenting each use case from the perspective of the = data consumer, data subject, and data supplier would likely shed light = on what is needed. -andy= From leifj@mnt.se Fri Jun 15 05:35:15 2012 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 051EF21F8616 for ; Fri, 15 Jun 2012 05:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 QiXdRNb1ZU8P for ; Fri, 15 Jun 2012 05:35:14 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id D7DC621F85BD for ; Fri, 15 Jun 2012 05:35:13 -0700 (PDT) Received: from [192.36.125.244] (dhcp.pilsnet.sunet.se [192.36.125.244] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5FCZ7t7020174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jun 2012 14:35:11 +0200 (CEST) Message-ID: <4FDB2BFB.9020602@mnt.se> Date: Fri, 15 Jun 2012 14:35:07 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <58F25160-28BC-4F35-BE96-5AC22D35BF00@hxr.us> In-Reply-To: <58F25160-28BC-4F35-BE96-5AC22D35BF00@hxr.us> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] For transparency purposes. 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, 15 Jun 2012 12:35:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2012 02:22 PM, Andy Newton wrote: > Involvement of NLnet Labs and SIDN, especially from an > implementation perspective, is a good thing in my opinion. And I > trust Olaf to compartmentalize his roles. yep -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/bK/sACgkQ8Jx8FtbMZncJKwCeK++vqjRRZ6bFN2qfWwjZjNdU vHcAnjdO2D9/9TWfi/f9VFud9FxDAp9g =sXAf -----END PGP SIGNATURE----- From ebw@abenaki.wabanaki.net Fri Jun 15 05:47:40 2012 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 431D921F8621 for ; Fri, 15 Jun 2012 05:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=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 ZgdApWHT9a7b for ; Fri, 15 Jun 2012 05:47:39 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE921F85DF for ; Fri, 15 Jun 2012 05:47:39 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5F9dSkk082329 for ; Fri, 15 Jun 2012 05:39:29 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FDB2EE5.6070701@abenaki.wabanaki.net> Date: Fri, 15 Jun 2012 08:47:33 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> <4FDAB602.1000709@abenaki.wabanaki.net> <4FDABDCA.9020909@Commerco.Com> In-Reply-To: <4FDABDCA.9020909@Commerco.Com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 12:47:40 -0000 On 6/15/12 12:44 AM, Alan Maitland wrote: > On 6/14/2012 10:11 PM, Eric Brunner-Williams wrote: >> On 6/14/12 11:57 PM, Alan Maitland wrote: >>> Respectfully, privacy is very important ... >> >> and you're the first person to ever think of that. > > Taking a list member's statement out of context for effect is arguably > a cheap shot. The original poster appeared to think that privacy was > not relevant to the discussion at hand. I disagreed as regards design > considerations and discussions focused on the WIERDS specification. there are people who (a) think their local definition of {us contractual privacy|eu treaty of europe data protection|oedc hybrid} is global, and (b) that {privacy|dataprotection|hybrid} is "policy", for which no mechanism is properly the subject of specification. with that given, exactly what is your contribution to the specification under discussion? >>> Logically, I cannot think of any reason that a commercial business ... >> >> and how, mr. spock, do you propose to distinguish "commercial >> business" {numbers,names} registrants from any other registrants? > > It does not take much to actually ask in the registrant's registry > application for {names,numbers}. Also logically, it would make sense > to have a penalty associated with providing a provably invalid or > inaccurate response. again, you're the first person to ever think of that. alternatively, others have and they've been wildly successful at mechanically discerning registrant intent and purpose and cleaning up bad data in the cnobi registry set. > That said, this is the kind of thing is something for the registries > to determine how they would like to implement or not. The point is > that the specification must be flexible enough to address the need. could you be a bit more specific? are you asking for an evil bit the query respondent(s) can set to indicate some registration-time evident or post-registration discovered state of non-grace which the query originators can put to some use satisfying an existing, or novel, use case? as levin noted, see 3514. -e From andy@arin.net Fri Jun 15 07:06:12 2012 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 981E221F8794 for ; Fri, 15 Jun 2012 07:06:12 -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 YnWBpLnuFxhG for ; Fri, 15 Jun 2012 07:06:12 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id C38F021F878E for ; Fri, 15 Jun 2012 07:06:11 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id E20711652AE; Fri, 15 Jun 2012 10:06:10 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 54DF116528A for ; Fri, 15 Jun 2012 10:06:10 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 15 Jun 2012 10:05:51 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.4]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0247.003; Fri, 15 Jun 2012 10:06:09 -0400 From: Andy Newton To: "weirds@ietf.org" Thread-Topic: JSON naming Thread-Index: AQHNSwABxnfGbuSHJ0KAwmGkft/Ldw== Date: Fri, 15 Jun 2012 14:06:06 +0000 Message-ID: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <2506F48D38598446AF1BB5B9DE146EA4@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [weirds] JSON naming 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, 15 Jun 2012 14:06:12 -0000 In working on the Using HTTP draft, I've attempted to make clearer the JSON= naming section since it received feedback on this list and my sense is tha= t parts of it were confusing. Hopefully this is clearer. Since the draft i= s not yet ready for publication but I want feedback on this, I'm sending ju= st this section. Your comments are much appreciated. -andy 6.2. Naming Clients processing JSON [RFC4627] responses SHOULD ignore values associated with unrecognized names. Servers MAY insert values signified by names into the JSON responses which are not specified in this document. Insertion of unspecified values into JSON responses SHOULD have names prefixed with a short identifier followed by an underscore followed by a meaningful name. For example, a JSON object may have "handle" and "remarks" formally documented in a specification. Clients adhering to that specification will have appropriate knowledge of the meaning of "handle" and "remarks". Consider the following JSON response with JSON names. { "handle" : "ABC123", "remarks" : [ "she sells seas shells", "down by the seashore" ] } Figure 3 If The Registry of the Moon desires to express information not found in the specification, it might select "lunarNic" as its identifying prefix and insert, as an example, the name "lunarNic_beforeOneSmallStep" to signify registrations occuring before the first moon landing and the name "lunarNic_harshMistressNotes" containing other descriptive text. Consider the following JSON response with JSON names, some of which should be ignored by clients without knowledge of their meaning. { "handle" : "ABC123", "lunarNic_beforeOneSmallStep" : "TRUE THAT!", "remarks" : [ "she sells seas shells", "down by the seashore" ], "lunarNic_harshMistressNotes" : [ "In space,", "nobody can hear you scream." ] } Figure 4 Insertion of unrecognized names ignored by clients may also be used for future revisions to specifications and specifications deriving extensions from a base specification. JSON names SHOULD only consist of the alphabetic ASCII characters A through Z in both uppercase and lowercase, the numerical digits 0 through 9, underscore characters, and SHOULD NOT begin with an underscore character, numerical digit or the characters "xml". The following describes the produciton of JSON names in ABNF [RFC5234]. ABNF for JSON names name =3D ALPHA *( ALPHA / DIGIT / "_" ) Figure 5 This restriction is a union of the Ruby programming language identifier syntax and the XML element name syntax and has two purposes. First, client implementers using modern programming languages such as Ruby or Java may use libraries that automatically promote JSON names to first order object attributes or members (e.g. using the example above, the values may be referenced as network.handle or network.lunarNic_beforeOneSmallStep). Second, a clean mapping between JSON and XML is easy to accomplish using the JSON representation. Clients processing JSON responses MUST be prepared for values specified in the registry response documents to be absent from a response as no JSON value listed is required to appear in the response. In other words, servers MAY remove values as is needed by the policies of the server operator. From leifj@mnt.se Fri Jun 15 07:18:12 2012 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 69DA021F86C6 for ; Fri, 15 Jun 2012 07:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCRx1UYCqy-P for ; Fri, 15 Jun 2012 07:18:11 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 748D921F877A for ; Fri, 15 Jun 2012 07:18:11 -0700 (PDT) Received: from [109.105.104.174] (dhcp40.se-tug.nordu.net [109.105.104.174] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5FEI6Fi001149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 15 Jun 2012 16:18:10 +0200 (CEST) Message-ID: <4FDB441E.4000001@mnt.se> Date: Fri, 15 Jun 2012 16:18:06 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> In-Reply-To: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] JSON naming 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, 15 Jun 2012 14:18:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2012 04:06 PM, Andy Newton wrote: > In working on the Using HTTP draft, I've attempted to make clearer > the JSON naming section since it received feedback on this list and > my sense is that parts of it were confusing. Hopefully this is > clearer. Since the draft is not yet ready for publication but I > want feedback on this, I'm sending just this section. > > Your comments are much appreciated. > Another approach taken by SCIM is to stick extensions in their own structs and register the key thus: { "base": "spec", number: 1, "name": "bla", "urn:foo:my:extension": { "bla": 4711 } } -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/bRB4ACgkQ8Jx8FtbMZnfzSgCffEaZ9DARmoWMqPDqF79IAW8X XzoAoK6GHIq4DPmfyrSrTgQ+aF33l6+I =tGt0 -----END PGP SIGNATURE----- From johnl@iecc.com Fri Jun 15 08:04:50 2012 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 ACA0321F880C for ; Fri, 15 Jun 2012 08:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uqqs+hNrBBHS for ; Fri, 15 Jun 2012 08:04:50 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DF7E221F87DF for ; Fri, 15 Jun 2012 08:04:49 -0700 (PDT) Received: (qmail 44026 invoked from network); 15 Jun 2012 15:04:49 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Jun 2012 15:04:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fdb4f10.xn--btvx9d.k1206; i=johnl@user.iecc.com; bh=/PaesW454LYYIeC6Cn22gCkmQN4Kqpmb2dDgpCRumso=; b=KwzJju7+Sl1pUkFg/JPOWuST3TmGuIM6KeDsdJXR3XX4EBfcAeQ9vQSS0KKe5JCeirjxs6YaWJ4+eO7whXYKGxTUnsmcNrP68RtVjb4KEBv/ztxXbKMh/f9VknTZrZ6vAI4Vu25s82a4eT7htpJ7iRH0VPTSM1Xgmu1rmdvqkzY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 15 Jun 2012 15:04:26 -0000 Message-ID: <20120615150426.75151.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 15:04:50 -0000 >Perhaps a "Use Cases" draft is appropriate and would focus this conversation. Yes, please. That could be very helpful to people trying to implement this stuff. R's, John From andy@hxr.us Fri Jun 15 09:40:18 2012 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 E571121F84B4 for ; Fri, 15 Jun 2012 09:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFA0u-BqFcR3 for ; Fri, 15 Jun 2012 09:40:17 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CB63421F8455 for ; Fri, 15 Jun 2012 09:40:08 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2075733qcs.31 for ; Fri, 15 Jun 2012 09:40:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Nxt7F6x+Wl1O5s0kuvCJVAvMmCu/jeyX9zCSFfFK4qk=; b=XklP/7Y9PZdjeI2gthJz3+kGLHwedjNlvkctfdSCHfDOMfHBUWRJsyDQ28rhsHA4ZM lhjkYAmB+0m7f6/ynM3NS8eJqmYhRP/VVbIy1hrw4f39ohVpbJ4kGaiB+SYm07Gn2ing k0sYwckpCucxwNjWuLnmRuvKkit/XzrCye2zvgod/J+3+YH3tOf98Na/xtSkGzF/PxNX +9FQO3JrNoP40PI2Nt6PEOnNnM+d6i7DOsBuAyT1igifnsvkIvMFjPUDC6N6Bn/OG0ZM UDHC23T4FpPwi1TuPPzWwRheXGPwmG7QK1PzAL5o7EGSbPLTvSZ4RhT6JQoUq+EQh1lk 7NQA== Received: by 10.229.136.148 with SMTP id r20mr3240713qct.58.1339778408144; Fri, 15 Jun 2012 09:40:08 -0700 (PDT) Received: from andytop.arin.net (core.arin.net. [192.149.252.11]) by mx.google.com with ESMTPS id j12sm3278725qak.15.2012.06.15.09.40.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jun 2012 09:40:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andy Newton In-Reply-To: <20120615150426.75151.qmail@joyce.lan> Date: Fri, 15 Jun 2012 12:40:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <052CFC99-ED8B-4502-BA50-AFECF8760FC2@hxr.us> References: <20120615150426.75151.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlP+UnlKTEOQtVTLRbk9waadG/4Ud3mQU6I+jxYlgqrs5YD3R1o8iC9SasL6cSUtP+fvTbr Cc: weirds@ietf.org Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:40:18 -0000 On Jun 15, 2012, at 11:04 AM, John Levine wrote: >> Perhaps a "Use Cases" draft is appropriate and would focus this = conversation. >=20 > Yes, please. That could be very helpful to people trying to implement = this stuff. BTW, I was not volunteering to write it. :) -andy= From ajs@anvilwalrusden.com Fri Jun 15 09:42:13 2012 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 D655821F8592 for ; Fri, 15 Jun 2012 09:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 tVDC+V4shovj for ; Fri, 15 Jun 2012 09:42:13 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E021F84CD for ; Fri, 15 Jun 2012 09:42:13 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 890351ECB41C for ; Fri, 15 Jun 2012 16:42:12 +0000 (UTC) Date: Fri, 15 Jun 2012 12:42:03 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120615164203.GC30523@mail.yitter.info> References: <20120615150426.75151.qmail@joyce.lan> <052CFC99-ED8B-4502-BA50-AFECF8760FC2@hxr.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <052CFC99-ED8B-4502-BA50-AFECF8760FC2@hxr.us> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:42:14 -0000 On Fri, Jun 15, 2012 at 12:40:03PM -0400, Andy Newton wrote: > On Jun 15, 2012, at 11:04 AM, John Levine wrote: > > >> Perhaps a "Use Cases" draft is appropriate and would focus this conversation. > > > > Yes, please. That could be very helpful to people trying to implement this stuff. > > BTW, I was not volunteering to write it. :) I suppose, since I already listed three, I can volunteer. I don't expect we'll actually publish it, but we can have a draft to focus conversation. How's that? A -- Andrew Sullivan ajs@anvilwalrusden.com From AMaitland@Commerco.Com Fri Jun 15 11:00:11 2012 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 94D2B21F8624 for ; Fri, 15 Jun 2012 11:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_72=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 30ChYkBdu1Vg for ; Fri, 15 Jun 2012 11:00:10 -0700 (PDT) Received: from MS1.MailSys.Net (MS1.MailSys.Net [66.135.47.141]) by ietfa.amsl.com (Postfix) with ESMTP id 825AB21F8621 for ; Fri, 15 Jun 2012 11:00:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=mailsys; d=Commerco.Com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-fromip:x-fromcountry; b=QvG2LaYcFatbHUHEcOJToz6w5wZFUHDAkBx7BSAmES5n5tnAPHD8T9Uq6f9aGM9FKtc14BCmubimiFCjmkm9IyiAYrQX1xkLPYKVgm9ZdmnaO60Ljr9uB/UbafLSTU9HETP+aE/biwAkFQ57SNnHdIF25OF+9+S1bp/T9dVhPjY= Received: from [71.216.84.59] by MS1.MailSys.Net (ArGoSoft Mail Server .NET v.1.0.8.4) with ESMTP (EHLO [10.240.241.49]) for ; Fri, 15 Jun 2012 18:00:07 +0000 Message-ID: <4FDB7820.9030907@Commerco.Com> Date: Fri, 15 Jun 2012 12:00:00 -0600 From: Alan Maitland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDA2E65.9080000@tana.it> <4F2538C315ACAC42AD334C533C247C47565BDE59@bkexchmbx02.blacknight.local> <4FDAB29F.1090303@Commerco.Com> <4FDAB602.1000709@abenaki.wabanaki.net> <4FDABDCA.9020909@Commerco.Com> <4FDB2EE5.6070701@abenaki.wabanaki.net> In-Reply-To: <4FDB2EE5.6070701@abenaki.wabanaki.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FromIP: 71.216.84.59 X-FromCountry: US Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 18:00:11 -0000 On 6/15/2012 6:47 AM, Eric Brunner-Williams wrote: > On 6/15/12 12:44 AM, Alan Maitland wrote: >> On 6/14/2012 10:11 PM, Eric Brunner-Williams wrote: >>> On 6/14/12 11:57 PM, Alan Maitland wrote: >>>> Respectfully, privacy is very important ... >>> >>> and you're the first person to ever think of that. >> >> Taking a list member's statement out of context for effect is arguably >> a cheap shot. The original poster appeared to think that privacy was >> not relevant to the discussion at hand. I disagreed as regards design >> considerations and discussions focused on the WIERDS specification. > > there are people who (a) think their local definition of {us > contractual privacy|eu treaty of europe data protection|oedc hybrid} > is global, and (b) that {privacy|dataprotection|hybrid} is "policy", > for which no mechanism is properly the subject of specification. > > with that given, exactly what is your contribution to the > specification under discussion? From reading messages on the list, some members of the list are apparently supportive of a simpler specification, which appears to only address a common set of data across all registries (both names and numbers). It may prove challenging to get a consensus on that strategy from all the registries, as past efforts attempting to employ that approach have apparently not been greatly successful in their adoption. Others on the list are supportive of a more robust specification which addresses a foreseeable need to allow for all of the points of the "people who (a).. (b).." etc. It is precisely because data access and privacy needs differ in different parts of the world that it is important to consider those items in the specification. My observations were made in order to underscore agreement with the thinking that supports the broader based design for the specification, which would better address the varied needs of all the desperate registries (and laws under which they operation) through a common specification that attempts to address the real world considerations to which these registries must adhere. >>>> Logically, I cannot think of any reason that a commercial business ... >>> >>> and how, mr. spock, do you propose to distinguish "commercial >>> business" {numbers,names} registrants from any other registrants? >> >> It does not take much to actually ask in the registrant's registry >> application for {names,numbers}. Also logically, it would make sense >> to have a penalty associated with providing a provably invalid or >> inaccurate response. > > again, you're the first person to ever think of that. alternatively, > others have and they've been wildly successful at mechanically > discerning registrant intent and purpose and cleaning up bad data in > the cnobi registry set. > You asked a question and I proffered an answer. As you allude, others agree with my answer (of course, I was not the first to think of that). However, if you did not want an answer or simply asked to fire off another remark of questionable intent, I would submit, that you should probably not ask in the first place. >> That said, this is the kind of thing is something for the registries >> to determine how they would like to implement or not. The point is >> that the specification must be flexible enough to address the need. > > could you be a bit more specific? are you asking for an evil bit the > query respondent(s) can set to indicate some registration-time evident > or post-registration discovered state of non-grace which the query > originators can put to some use satisfying an existing, or novel, use > case? as levin noted, see 3514. WIERDS is not a specification for a reputation system. That said, in addressing the possible foreseeable needs of the registries as regards data private/public data exchange by way of example, it might be convenient from a security standpoint (for the purpose of the example) to allow for some way to (minimally) track and classify the currently observed behavior of any registrant. By way of analogy, in some arbitrary global location, if you have people at your party who are engaged in illegal or questionable activity, then you, as the host, have a moral obligation to your other well behaved guests to address the behavior of the one engaged in the problem activity. If you have no way to track or identify who the problem party goers are, you have failed in your duties as a good host. In some other parts of the world, perhaps that is not the case (i.e., because the moral imperative may be different). So again, having a robust specification addressing certain data important to a subset of registries, but not needing to enforce a requirement for said data on other registries who may not need or be allowed to keep such data, allows each registry adopter the option of enabling or not enabling various data for use within a common shared framework. That thinking would appear a useful thing to embed into a specification with a population of registrars with disparate data gathering/reporting needs. Finally, John Levine's post to the list referencing RFC 3514 was indeed enjoyed and quite a bit of fun. I suspect this as his intent in making that contribution to the discussion thread. > > -e Alan From ebw@abenaki.wabanaki.net Fri Jun 15 13:00:59 2012 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 0B4E111E809C for ; Fri, 15 Jun 2012 13:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 wIGCD4lt2LjD for ; Fri, 15 Jun 2012 13:00:58 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 60BB311E808A for ; Fri, 15 Jun 2012 13:00:58 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5FGqhmZ083577 for ; Fri, 15 Jun 2012 12:52:43 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FDB9474.5050709@abenaki.wabanaki.net> Date: Fri, 15 Jun 2012 16:00:52 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <20120615150426.75151.qmail@joyce.lan> <052CFC99-ED8B-4502-BA50-AFECF8760FC2@hxr.us> <20120615164203.GC30523@mail.yitter.info> In-Reply-To: <20120615164203.GC30523@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 20:00:59 -0000 > I suppose, since I already listed three, I can volunteer. ... good for you ;-) some possibilities: 1. fastflux, frequent changes to rrset, so "are there" in query to zone editor, or a temporal window in which two or more changes took place, a "yes" condition waives jurisdictionally appropriate bar on publication. the condition relates to use "for good" of the technique, for which examples exist. 2. typosquat, string within damerau-levenshtein metric of registered mark. again, a yes waives ... and we may have a database of registered marks in the near future (icann policy playpen). 3. fraud, requires a "payment not repudiated" toggle, a modify bit that can be tossed over the fence (to ourselves) in the provisioning policy playpen. for all those credit card "purchases" that last only hours or days before being scotched. alt, registrars that don't take cards, e.g., mine, ignore exception for queries made for registrations within the industry payment repudiation window, e.g., 30 days. 4. algorithmic names, .C variant, if name is within registered cluster, which requires cluster registration conveniences, then a yes waives ... 5. display property of names, this is something we tried to make unnecessary in idna (latest) but it remains an area for exploits and registry error, infix "1" (as "l") in an alpha sequence, etc, for any script supported. none of these attempt to divine the purpose of the registrant, just some common properties of strings, or rrsets, that come to mind. -e From ebw@abenaki.wabanaki.net Fri Jun 15 13:44:01 2012 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 D136421F855B for ; Fri, 15 Jun 2012 13:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 0+B1bM1rlg4B for ; Fri, 15 Jun 2012 13:44:01 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7C22721F8552 for ; Fri, 15 Jun 2012 13:43:55 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5FHZeRL083733 for ; Fri, 15 Jun 2012 13:35:40 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FDB9E85.5000801@abenaki.wabanaki.net> Date: Fri, 15 Jun 2012 16:43:49 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <20120615150426.75151.qmail@joyce.lan> <052CFC99-ED8B-4502-BA50-AFECF8760FC2@hxr.us> <20120615164203.GC30523@mail.yitter.info> In-Reply-To: <20120615164203.GC30523@mail.yitter.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 20:44:02 -0000 On 6/15/12 12:42 PM, Andrew Sullivan wrote: > ... I don't > expect we'll actually publish it, but we can have a draft to focus > conversation. How's that? upon reflection i think it is inadequate. the whole point of use cases is to state the problems to be solved, in a particular narrative or stylistic form. non-publication means only the archival work products, the mailing list, and drafts that are ultimately left to expire, present the problem(s) to be solved purpose of any published specification. the future modification implementers will have to discover "why did they do that" for themselves, possibly arriving at the same conclusion as the specification's earlier authors. [check: can you figure out why we did what we did for each obscure edge case in the idna2003 doc set from the doc set? does reading klensin's lengthy and occasionally tangled prose answer all your questions for something as recent as idna-latest?] further, since this, wierds, is supposed to finally settle the festering hash of names, and without loss of generality or harm, be useful for numbers, several sacred cows are ... slated for the barbi. explaining why privacy|dataprotection is and isn't observed via the several use cases means the affected users of registry systems, and the operators of components of registry systems, will have a clue as to what semantic attaches via what syntax to what underlying datum, and how exceptions to general rules are defined and implemented. so i suggest the editor aim for publication, and not merely informational. -e From ebw@abenaki.wabanaki.net Fri Jun 15 15:21:50 2012 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 D286921F8593 for ; Fri, 15 Jun 2012 15:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ZjTQxZ6gGUnN for ; Fri, 15 Jun 2012 15:21:50 -0700 (PDT) Received: from nic-naa.net (nic-naa.net [65.99.1.132]) by ietfa.amsl.com (Postfix) with ESMTP id 0E09D21F851B for ; Fri, 15 Jun 2012 15:21:49 -0700 (PDT) Received: from limpet-2.local (cpe-67-255-3-6.twcny.res.rr.com [67.255.3.6]) by nic-naa.net (8.14.4/8.14.4) with ESMTP id q5FJDWPj084072 for ; Fri, 15 Jun 2012 15:13:34 -0400 (EDT) (envelope-from ebw@abenaki.wabanaki.net) Message-ID: <4FDBB576.3050105@abenaki.wabanaki.net> Date: Fri, 15 Jun 2012 18:21:42 -0400 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 22:21:51 -0000 On 6/12/12 1:17 PM, Bob Bruen wrote: > > The current whois is swamp of problems, some technical (like formats), > but mostly policy. The ICANN RAA contract is currently > unenforcable. Legal requirements for registr[ars|ies] do not exist. there are three assertions above. the first is true, the second false, the third also false. the second and third are also irrelevant to the problem of specification of a reporting mechanism for data held in names and numbers registries, nominally the non-falseness of the first assertion. -e From alexandrsergeyev@gmail.com Fri Jun 15 20:22:31 2012 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 3839C11E8119 for ; Fri, 15 Jun 2012 20:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEh7GxATrt3V for ; Fri, 15 Jun 2012 20:22:30 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5D311E811A for ; Fri, 15 Jun 2012 20:22:30 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2393229wgb.13 for ; Fri, 15 Jun 2012 20:22:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=9k550arHxA06Z/e5urwFDqHoSeZ7HYsfiwK1HaMdLKU=; b=XSqYkQbqcA6yo2Q7HXya+kGMnvQzuOJLbtcieg0IpRKSWQOR7AJrDWGJboK8pMx9H6 Icv9SmtwUOE7sLPK6wvFyMjlYU5TtikUb0yTaGZpCPeu0zq7ktihDa5nNnlPLB54RvwP /j31+lzSVv/r1jN+kcc8+WDf8f/G3SUKdxYWY8l8chv0scz8Kz4XkKqMrdOeRU+ORh8x SI7O2Jo94GbVJIOMUYB6aD1OUpJ/7Zl/ZuRBhqBTDPlIOBJ9xdVb2LrO9oCBQxe6q1oi C3vRcNsehZO6D+yPbzmI4KH3sR6UoGhfg92ke5sGm5orrhntsHRp1oZPzZHT5L2i2TKe 4rXQ== MIME-Version: 1.0 Received: by 10.216.218.77 with SMTP id j55mr3976294wep.179.1339816949328; Fri, 15 Jun 2012 20:22:29 -0700 (PDT) Sender: alexandrsergeyev@gmail.com Received: by 10.216.49.16 with HTTP; Fri, 15 Jun 2012 20:22:29 -0700 (PDT) In-Reply-To: <4FDB441E.4000001@mnt.se> References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> Date: Fri, 15 Jun 2012 23:22:29 -0400 X-Google-Sender-Auth: lUOZ7Dc0EyfARBHNTdL2o0M9ets Message-ID: From: Alex Sergeyev To: Leif Johansson , weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [weirds] JSON naming 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, 16 Jun 2012 03:22:31 -0000 On Fri, Jun 15, 2012 at 10:18 AM, Leif Johansson wrote: > On 06/15/2012 04:06 PM, Andy Newton wrote: >> In working on the Using HTTP draft, I've attempted to make clearer >> the JSON naming section... >> ... >> First, client implementers using modern programming >> languages such as Ruby or Java may use libraries that automatically >> promote JSON names to first order object attributes or members... > Another approach taken by SCIM is to stick extensions in > their own structs and register the key thus: > > { > "base": "spec", > number: 1, > "name": "bla", > "urn:foo:my:extension": { "bla": 4711 } > } Nice, something I can talk about :) If you ask me "would programmers have problem with 'urn:foo:my:extension' ", I'd say "NO". There is nothing that prevents anyone from using those keys in Javascript nor Ruby (I don't think I've seen Java doing properties from JSON but I know very little of it, might be worth to check if you use it). Both Javascript and Ruby (and I'd say here Python and Perl too) also will not have problems with keys in non latin-1 encoding. BUT I like idea of making life of developers a bit easier. We don't know what tools might be out there that would require "decent" keys, at least at top level of the structure to nicely store WEIRDS results. I can imagine someone using DB to store data from keys they care about. Who knows. Also converting names 1:1 to plain vanilla, no-namespace XML would be so much easier (and, if you wish, transforming it to neat, some-schema-conforming using XSLT). Andy's naming "policy" is not limiting too much and not requires "prefixes". I'd support that. Alex. From leifj@mnt.se Sat Jun 16 14:46:28 2012 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 458B021F85C9 for ; Sat, 16 Jun 2012 14:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 BDwqiC4GxH43 for ; Sat, 16 Jun 2012 14:46:27 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0E38721F85C5 for ; Sat, 16 Jun 2012 14:46:26 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5GLkGel019894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Jun 2012 23:46:20 +0200 (CEST) Message-ID: <4FDCFE89.7090409@mnt.se> Date: Sat, 16 Jun 2012 23:45:45 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alex Sergeyev References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] JSON naming 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, 16 Jun 2012 21:46:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/16/2012 05:22 AM, Alex Sergeyev wrote: > On Fri, Jun 15, 2012 at 10:18 AM, Leif Johansson > wrote: > >> On 06/15/2012 04:06 PM, Andy Newton wrote: >>> In working on the Using HTTP draft, I've attempted to make >>> clearer the JSON naming section... ... First, client >>> implementers using modern programming languages such as Ruby or >>> Java may use libraries that automatically promote JSON names to >>> first order object attributes or members... > >> Another approach taken by SCIM is to stick extensions in their >> own structs and register the key thus: >> >> { "base": "spec", number: 1, "name": "bla", >> "urn:foo:my:extension": { "bla": 4711 } } > > > Nice, something I can talk about :) > > If you ask me "would programmers have problem with > 'urn:foo:my:extension' ", I'd say "NO". There is nothing that > prevents anyone from using those keys in Javascript nor Ruby (I > don't think I've seen Java doing properties from JSON but I know > very little of it, might be worth to check if you use it). Both > Javascript and Ruby (and I'd say here Python and Perl too) also > will not have problems with keys in non latin-1 encoding. > > BUT > > I like idea of making life of developers a bit easier. We don't > know what tools might be out there that would require "decent" > keys, at least at top level of the structure to nicely store WEIRDS > results. > > I can imagine someone using DB to store data from keys they care > about. Who knows. Also converting names 1:1 to plain vanilla, > no-namespace XML would be so much easier (and, if you wish, > transforming it to neat, some-schema-conforming using XSLT). > > Andy's naming "policy" is not limiting too much and not requires > "prefixes". I'd support that. > > > > Alex. Being a coder myself (at least sometimes) I know that ':' in strings isn't an issue. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/c/okACgkQ8Jx8FtbMZncvagCgtg/Ghif4sBxwSFOWxOjWn7mu XAEAoMQ0iv95bObvRuvRlpzQeyoYesNb =ZbXl -----END PGP SIGNATURE----- From alexandrsergeyev@gmail.com Sat Jun 16 19:22:35 2012 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 E6F9E11E8079 for ; Sat, 16 Jun 2012 19:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDQrkjcq8mm4 for ; Sat, 16 Jun 2012 19:22:35 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F10A11E8073 for ; Sat, 16 Jun 2012 19:22:35 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5802462obb.31 for ; Sat, 16 Jun 2012 19:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=6XZkGfr4KXm7SB4NkGComGqwpLTh/otQDnnDpja0Lbw=; b=VHdnzxpXsT9VzR4WhgOltgfhtJ4TwaU4EI/kw5N2wI2+/OVTMPkLbtGaMAOSwq4AAo eijpUhGMlbBfHqxypkW36s8gKveG9DVWOcJmohX+tJBuDZ0aJw/6VZ+BVSkv/IlAHxGP WN7djAGNDaxu/dzUJilM3vBbcn5Pw4Esq1Kp2Gz+LUdQPYTOueKuab/3EBFLXicl04k/ 5LLD2QetbwaLpepu2xty0SEyHt/Vq5h2x7/ib0El3IBYFSh8WsGFa3m07D/FgkiTMq1v 0zVx3prcK8nqSSRNGLYbv9quKWUg0U4JtUHvWZBq8GEBFauyiDlbgsDzA4mxGH/9hSSy S9+Q== MIME-Version: 1.0 Received: by 10.182.38.66 with SMTP id e2mr11040970obk.31.1339899754603; Sat, 16 Jun 2012 19:22:34 -0700 (PDT) Sender: alexandrsergeyev@gmail.com Received: by 10.76.22.111 with HTTP; Sat, 16 Jun 2012 19:22:34 -0700 (PDT) In-Reply-To: <4FDCFE89.7090409@mnt.se> References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> <4FDCFE89.7090409@mnt.se> Date: Sat, 16 Jun 2012 22:22:34 -0400 X-Google-Sender-Auth: Kq_XLI-p7qi-rzq7GavRCA86vp4 Message-ID: From: Alex Sergeyev To: Leif Johansson , weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [weirds] JSON naming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 02:22:36 -0000 Leif, > Being a coder myself (at least sometimes) I know that ':' in > strings isn't an issue. But what value do you see using them in WEIRDS JSON output structures? I'd like to hear some reasons because so far I just think XML when I see urn:somename and stumbling on it in JSON is very odd to me.... I also think that eventually it'll be strange when some keys have ":", and some do not. And when it'll be time, to find commonalities in how people use weirds and make v2, with more "recommended keys" it would require to switch already used names with ":" to names without it. I'd rather to see all names "plain" from the start. -- Alex Sergeyev. From leifj@mnt.se Sun Jun 17 00:11:22 2012 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 9299121F847B for ; Sun, 17 Jun 2012 00:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.434 X-Spam-Level: X-Spam-Status: No, score=-3.434 tagged_above=-999 required=5 tests=[AWL=-1.831, BAYES_00=-2.599, J_CHICKENPOX_38=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaB0HOD8AMQ8 for ; Sun, 17 Jun 2012 00:11:21 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1F821F8475 for ; Sun, 17 Jun 2012 00:11:20 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so4044082lbb.31 for ; Sun, 17 Jun 2012 00:11:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=eVP3qqNOGEuODezqhkSg4fijlBi8bu4tF2ACIPzjl/I=; b=EpCHDa13rZtriLKvaAjQOLfdkrVDPQyrXbYcnV/x6EaQZYHa8Bzswnugo+R1TCens3 i5RNSDFCj3TaVTCsAA/S4JBIdfPDCZ41mFrSU+86PocYRlqbhnIzMzWTMgqKhpFvMz/v PL4Jy4VZolDOTmY8R1lMD58jfOC07JsiX1spZbBtmTM+sd5Jj7OX62+ms+M8loiwhbqD 1ekh9dAUiSPtW2gBwaCctrzw02BY8bzUNc0/7anBFYo1K2/4tXY871RHgLxlxYCaEkDs +xvqtf8OI+aBFjrj+YAXpJJ4h/HsxXD/11D5TxRVk9PGBTi389JwMmDMF0SR6zJJtO9/ 6YBA== Received: by 10.112.101.169 with SMTP id fh9mr4916028lbb.18.1339917079389; Sun, 17 Jun 2012 00:11:19 -0700 (PDT) Received: from [10.0.0.232] (ua-83-227-179-169.cust.bredbandsbolaget.se. [83.227.179.169]) by mx.google.com with ESMTPS id k4sm9151716lbb.12.2012.06.17.00.11.16 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 17 Jun 2012 00:11:18 -0700 (PDT) References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> <4FDCFE89.7090409@mnt.se> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0438A104-86D2-4C73-B739-7085CFAC1D1D@mnt.se> X-Mailer: iPad Mail (9B206) From: Leif Johansson Date: Sun, 17 Jun 2012 09:11:14 +0200 To: Alex Sergeyev X-Gm-Message-State: ALoCoQlq164R1JQmcyfG1IuLMZ3rdLbTttSKZZpgxHM7j2JbRyuiD+upl0VH696V6vQq8cuXGWCQ Cc: "weirds@ietf.org" Subject: Re: [weirds] JSON naming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 07:11:22 -0000 17 jun 2012 kl. 04:22 skrev Alex Sergeyev : > Leif, >=20 >> Being a coder myself (at least sometimes) I know that ':' in >> strings isn't an issue. >=20 > But what value do you see using them in WEIRDS JSON output structures? >=20 Conflict avoidance, but it was really just an example: an IANA registry of "= short" identifiers would work just as well. > I'd like to hear some reasons because so far I just think XML when I > see urn:somename and stumbling on it in JSON is very odd to me.... I don't understand that. >=20 > I also think that eventually it'll be strange when some keys have ":", > and some do not. I don't get that either. >=20 > And when it'll be time, to find commonalities in how people use weirds > and make v2, with more "recommended keys" it would require to switch > already used names with ":" to names without it. I'd rather to see all > names "plain" from the start. >=20 >=20 > --=20 > Alex Sergeyev. From bob@coldrain.net Sun Jun 17 04:43:20 2012 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 B610121F85F7 for ; Sun, 17 Jun 2012 04:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.157 X-Spam-Level: X-Spam-Status: No, score=-1.157 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ--1hQWcXs9 for ; Sun, 17 Jun 2012 04:43:20 -0700 (PDT) Received: from coldrain.net (host49.duncable.cust.sover.net [209.198.81.49]) by ietfa.amsl.com (Postfix) with ESMTP id EBA0321F85A5 for ; Sun, 17 Jun 2012 04:43:19 -0700 (PDT) Received: from coldrain.net (localhost.localdomain [127.0.0.1]) by coldrain.net (8.13.8/8.13.8) with ESMTP id q5HBhBxV027903; Sun, 17 Jun 2012 07:43:12 -0400 Received: from localhost (bob@localhost) by coldrain.net (8.13.8/8.13.8/Submit) with ESMTP id q5HBhAlH027900; Sun, 17 Jun 2012 07:43:11 -0400 Date: Sun, 17 Jun 2012 07:43:10 -0400 (EDT) From: Bob Bruen To: Eric Brunner-Williams In-Reply-To: <4FDBB576.3050105@abenaki.wabanaki.net> Message-ID: References: <4FDBB576.3050105@abenaki.wabanaki.net> User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] FW: I-D Action: draft-kong-dnrd-ap-response-json-00.txt X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 11:43:20 -0000 Hi Eric, I guess you missed this article: http://www.circleid.com/posts/20120312_icanns_contract_not_enforceable_on_whois_accuracy/ ICANN has acknowledged its veracity. I was not clear in my statements. I meant "unenforcable" and "Legal requirements" in terms of whois in the RAA contract. "Irrelevant?" Maybe. --bob On Fri, 15 Jun 2012, Eric Brunner-Williams wrote: > On 6/12/12 1:17 PM, Bob Bruen wrote: >> >> The current whois is swamp of problems, some technical (like formats), >> but mostly policy. The ICANN RAA contract is currently >> unenforcable. Legal requirements for registr[ars|ies] do not exist. > > there are three assertions above. the first is true, the second false, > the third also false. > > the second and third are also irrelevant to the problem of > specification of a reporting mechanism for data held in names and > numbers registries, nominally the non-falseness of the first assertion. > > -e > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > -- Dr. Robert Bruen http://knujon.org http://coldrain.net/bruen +1.802.579.6288 From johnl@iecc.com Sun Jun 17 08:27:32 2012 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 E114821F85A0 for ; Sun, 17 Jun 2012 08:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.199 X-Spam-Level: X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H26kuIVtZShe for ; Sun, 17 Jun 2012 08:27:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9F621F8592 for ; Sun, 17 Jun 2012 08:27:31 -0700 (PDT) Received: (qmail 22077 invoked from network); 17 Jun 2012 15:27:30 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 17 Jun 2012 15:27:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fddf762.xn--i8sz2z.k1206; i=johnl@user.iecc.com; bh=5UsLVzdRIiR/7vsfa9B/Ux0rQOyV0xPfKCMlXgJZKZ0=; b=Ig4x/HqcMTvooLbcykuWNLlo/Gw+l2Nir2V15zZbVPiw2vDcx6TZ+ZV0NbhA6V2hQKTJfRd+E7m3ODbf2eaDnk8IHdbwJwVXLAfl/IewgGFXWyn4nu/ynLCtI6lco/ktnZOnMeZGqFdgR8/YNI3SVZWFG01+6JgGBW0leZl/+Sc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 17 Jun 2012 15:27:08 -0000 Message-ID: <20120617152708.34963.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <0438A104-86D2-4C73-B739-7085CFAC1D1D@mnt.se> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] JSON naming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 15:27:33 -0000 >Conflict avoidance, but it was really just an example: an IANA registry of >"short" identifiers would work just as well. Even that seems like overkill. The plan, as I understand it, is to produce an RFC, or maybe two RFCs, that describe the response formats, including the fields names. No conflict there. If someone wants to do a revised version, there'll be a new RFC. I suppose that if we anticipate large numbers of small extensions, it might make sense to have an IANA registry for the field names, but speaking as someone who's planning to write and use WEIRDS clients, please don't do that. R's, John From leifj@mnt.se Sun Jun 17 11:52:54 2012 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 41B2D21F85C6 for ; Sun, 17 Jun 2012 11:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 z3h6AcKy67q6 for ; Sun, 17 Jun 2012 11:52:53 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0C11621F85B5 for ; Sun, 17 Jun 2012 11:52:52 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5HIqc3L000196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Jun 2012 20:52:42 +0200 (CEST) Message-ID: <4FDE2776.60809@mnt.se> Date: Sun, 17 Jun 2012 20:52:38 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Levine References: <20120617152708.34963.qmail@joyce.lan> In-Reply-To: <20120617152708.34963.qmail@joyce.lan> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] JSON naming X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 18:52:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/17/2012 05:27 PM, John Levine wrote: >> Conflict avoidance, but it was really just an example: an IANA >> registry of "short" identifiers would work just as well. > > Even that seems like overkill. The plan, as I understand it, is > to produce an RFC, or maybe two RFCs, that describe the response > formats, including the fields names. No conflict there. If > someone wants to do a revised version, there'll be a new RFC. > > I suppose that if we anticipate large numbers of small extensions, > it might make sense to have an IANA registry for the field names, > but speaking as someone who's planning to write and use WEIRDS > clients, please don't do that. If you don't care about extensibility (and maybe you don't) then that will work just fine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/eJ3UACgkQ8Jx8FtbMZneFvgCbBP1BrHqmg3zuTzSpSfcAWy6A 56UAn0yyklmkj+GafcBLucLZ3E1YI0DX =3vhQ -----END PGP SIGNATURE----- From zhoulinlin@cnnic.cn Sun Jun 17 22:51:01 2012 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 7B1F021F84D6 for ; Sun, 17 Jun 2012 22:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_38=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 JXAluhm9OVA3 for ; Sun, 17 Jun 2012 22:51:01 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 4E87121F84AF for ; Sun, 17 Jun 2012 22:50:57 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 18 Jun 2012 13:50:53 +0800 From: "Linlin Zhou" To: "'Leif Johansson'" , "'Alex Sergeyev'" References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> <4FDCFE89.7090409@mnt.se> <0438A104-86D2-4C73-B739-7085CFAC1D1D@mnt.se> In-Reply-To: <0438A104-86D2-4C73-B739-7085CFAC1D1D@mnt.se> Date: Mon, 18 Jun 2012 13:50:52 +0800 Message-ID: <000301cd4d16$531d2290$f95767b0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1MWG8yx4V67sisSyCGjlw5S16oJAAqOS2w Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] JSON naming 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, 18 Jun 2012 05:51:01 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On Behalf Of > Leif Johansson > Sent: Sunday, June 17, 2012 3:11 PM > To: Alex Sergeyev > Cc: weirds@ietf.org > Subject: Re: [weirds] JSON naming > > > > > > 17 jun 2012 kl. 04:22 skrev Alex Sergeyev : > > > Leif, > > > >> Being a coder myself (at least sometimes) I know that ':' in strings > >> isn't an issue. > > > > But what value do you see using them in WEIRDS JSON output structures? > > > > Conflict avoidance, but it was really just an example: an IANA registry of > "short" identifiers would work just as well. > > > I'd like to hear some reasons because so far I just think XML when I > > see urn:somename and stumbling on it in JSON is very odd to me.... > > I don't understand that. > urn:somename is the namespace used in XML to avoid keys collisions. I think namespaces is templates that say what data is permitted and what value to give data that is not defined. JSON is a simple and light weighted protocol, so if a namespace is added, shall we have to first check whether all the objects included in the namespace? If so, I think it's a little complicated. > > > > I also think that eventually it'll be strange when some keys have ":", > > and some do not. > > I don't get that either. > colon in JSON keys depending on coding style > > > > And when it'll be time, to find commonalities in how people use weirds > > and make v2, with more "recommended keys" it would require to switch > > already used names with ":" to names without it. I'd rather to see all > > names "plain" from the start. > > > > > > -- > > Alex Sergeyev. > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From dave.piscitello@icann.org Sun Jun 17 23:01:09 2012 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 F3D8B21F855E for ; Sun, 17 Jun 2012 23:01:08 -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 dZo7NXSB8DKd for ; Sun, 17 Jun 2012 23:01:08 -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 3256421F848A for ; Sun, 17 Jun 2012 23:01:08 -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; Sun, 17 Jun 2012 23:01:08 -0700 From: Dave Piscitello To: Leif Johansson Date: Sun, 17 Jun 2012 23:00:29 -0700 Thread-Topic: [weirds] JSON naming Thread-Index: Ac1NF8DPb2mPdJobTcWIq96Pv1Lg2A== Message-ID: References: <20120617152708.34963.qmail@joyce.lan> <4FDE2776.60809@mnt.se> In-Reply-To: <4FDE2776.60809@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] JSON naming 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, 18 Jun 2012 06:01:09 -0000 I don't see how john's vision excludes extensibility=20 Sent from my iPhone On Jun 17, 2012, at 8:53 PM, "Leif Johansson" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 06/17/2012 05:27 PM, John Levine wrote: >>> Conflict avoidance, but it was really just an example: an IANA >>> registry of "short" identifiers would work just as well. >>=20 >> Even that seems like overkill. The plan, as I understand it, is >> to produce an RFC, or maybe two RFCs, that describe the response >> formats, including the fields names. No conflict there. If >> someone wants to do a revised version, there'll be a new RFC. >>=20 >> I suppose that if we anticipate large numbers of small extensions, >> it might make sense to have an IANA registry for the field names, >> but speaking as someone who's planning to write and use WEIRDS >> clients, please don't do that. >=20 > If you don't care about extensibility (and maybe you don't) then > that will work just fine. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk/eJ3UACgkQ8Jx8FtbMZneFvgCbBP1BrHqmg3zuTzSpSfcAWy6A > 56UAn0yyklmkj+GafcBLucLZ3E1YI0DX > =3D3vhQ > -----END PGP SIGNATURE----- > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From leifj@mnt.se Sun Jun 17 23:09:39 2012 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 EB1CB11E808E for ; Sun, 17 Jun 2012 23:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.966 X-Spam-Level: X-Spam-Status: No, score=-2.966 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, J_CHICKENPOX_38=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 msyQutvs7c7x for ; Sun, 17 Jun 2012 23:09:39 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B297A11E808A for ; Sun, 17 Jun 2012 23:09:38 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5I69P5f021746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 08:09:29 +0200 (CEST) Message-ID: <4FDEC615.70401@mnt.se> Date: Mon, 18 Jun 2012 08:09:25 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Linlin Zhou References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> <4FDCFE89.7090409@mnt.se> <0438A104-86D2-4C73-B739-7085CFAC1D1D@mnt.se> <000301cd4d16$531d2290$f95767b0$@cn> In-Reply-To: <000301cd4d16$531d2290$f95767b0$@cn> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: [weirds] extensibility in weirds 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, 18 Jun 2012 06:09:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > urn:somename is the namespace used in XML to avoid keys > collisions. I think namespaces is templates that say what data is > permitted and what value to give data that is not defined. JSON is > a simple and light weighted protocol, so if a namespace is added, > shall we have to first check whether all the objects included in > the namespace? If so, I think it's a little complicated. > I still don't get what anyone is saying on this topic. Structured names (like URIs) have *nothing* do do with XML per se. They are neither more or less "complicated" than unstructured names and they do not affect code in any reasonable way. I was making a point about extensibility. Joe Levine seems to say that extensibility isn't necessarily in scope for weirds. If so then the issues we discuss in this thread are of no consequence to weirds and we can just stop this thread :-) If extensibility is needed and unless weirds wants to mandate that all extensions must be based on published specs then some form of uniqueness for JSON key names is needed. There are two ways to obtain uniqueness of identifiers: structured names or a registry. Take your pick. However this may all be a moot point if extensibility isn't needed so perhaps the WG should have consensus on that point first. > >>> >>> I also think that eventually it'll be strange when some keys >>> have ":", and some do not. >> >> I don't get that either. >> > > colon in JSON keys depending on coding style No it doesn't. These are not variables. JSON is not code but a data representation language. Saying "colons are bad" is only true for variable names in certain languages but no programming language that I've ever encountered has problems with colons in strings. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/exhQACgkQ8Jx8FtbMZne4fQCeKUkyaeUZr/SJQGKS4fH8QJdX DOcAn0vzF0+K7LR3b0BjtaXJ8ZGf64iP =w1jw -----END PGP SIGNATURE----- From superuser@gmail.com Mon Jun 18 01:33:14 2012 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 5C63F21F84EC for ; Mon, 18 Jun 2012 01:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q28ckgUjMdy0 for ; Mon, 18 Jun 2012 01:33:13 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23EF621F84D9 for ; Mon, 18 Jun 2012 01:33:10 -0700 (PDT) Received: by lagv3 with SMTP id v3so3484735lag.31 for ; Mon, 18 Jun 2012 01:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MOfz7+AecqQZC2qK81yUD6+U1I37DsKp/ExLTcR+MuI=; b=WTlF6iQo5itP/Kmr2cgXnZ5ocCCOgIzgw8GonxzJcS+57va/s9hS+sBIJ+wRKFsIYT mZVc+/AcNV6c6gHYA5ALRc/6vw6v0dB5RO3l+Z3UItvX6O/T+waQJdTqye6S6IfAZWyF oAZjd8dLS3TH8B9gP7FgX4w8gDWX4X8T/08Gt09MbgjG0jppzpEENnw/UoUrj/Xu/bAf 2SsQ/wxv4KDO4aaiBCSaAtaborxvPpRQ+mSv4k1xz5yNuC0yngmHqAaLMNFnBlwVdBE5 W1mUHx+8Si/n995S6E6bbugA3Ba+4PiwxT6E9qPsCt78XKg10Q/w97JOuUH1HZgPPPfE Zjgg== MIME-Version: 1.0 Received: by 10.112.84.168 with SMTP id a8mr6078645lbz.92.1340008389756; Mon, 18 Jun 2012 01:33:09 -0700 (PDT) Received: by 10.112.89.3 with HTTP; Mon, 18 Jun 2012 01:33:09 -0700 (PDT) In-Reply-To: References: <20120617152708.34963.qmail@joyce.lan> <4FDE2776.60809@mnt.se> Date: Mon, 18 Jun 2012 01:33:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Piscitello Content-Type: multipart/alternative; boundary=f46d04016cad11476404c2bb0411 Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] JSON naming 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, 18 Jun 2012 08:33:14 -0000 --f46d04016cad11476404c2bb0411 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jun 17, 2012 at 11:00 PM, Dave Piscitello wrote: > I don't see how john's vision excludes extensibility > > > Indeed, the "E" in "WEIRDS" stands for "extensible". -MSK --f46d04016cad11476404c2bb0411 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Jun 17, 2012 at 11:00 PM, Dave Piscitello <dave.piscitello= @icann.org> wrote:
I don't see how john's vision excludes extensibility



Indeed, the "E" in "WEIRDS&quo= t; stands for "extensible".

-MSK

--f46d04016cad11476404c2bb0411-- From vesely@tana.it Mon Jun 18 01:42:56 2012 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 A97B521F862B for ; Mon, 18 Jun 2012 01:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.317 X-Spam-Level: X-Spam-Status: No, score=-4.317 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 QdGBJryndy9a for ; Mon, 18 Jun 2012 01:42:56 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id CFF7D21F8542 for ; Mon, 18 Jun 2012 01:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1340008974; bh=RUcB/8XrNorna7Kzx4lQ1seOhSuG5V2fWeO+O+21S18=; l=1272; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Lv3bj4AQLB88FZGwMJ5Q7B7oRUOOI+ZBLxbpStiJnxfS/43ra79SheRjklptKLmQN jOht+vB0SJc4U+h/sgzZLA7S6r65Y8vSntNHGU1ZHiuGWkqFlAAPMijZg7fq7ibIgu OunDTjFhZ8QIeGY7KXP8ALdceUB53BVEOkmudtLA= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 18 Jun 2012 10:42:54 +0200 id 00000000005DC035.000000004FDEEA0E.000025A4 Message-ID: <4FDEEA0D.5050902@tana.it> Date: Mon, 18 Jun 2012 10:42:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> <4FDCFE89.7090409@mnt.se> <0438A104-86D2-4C73-B739-7085CFAC1D1D@mnt.se> <000301cd4d16$531d2290$f95767b0$@cn> <4FDEC615.70401@mnt.se> In-Reply-To: <4FDEC615.70401@mnt.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 08:42:56 -0000 On Mon 18/Jun/2012 08:09:25 +0200 Leif Johansson wrote: > > If extensibility is needed and unless weirds wants to mandate that all > extensions must be based on published specs then some form of uniqueness > for JSON key names is needed. Uniqueness would be implied by the data source if there are no provisions for "resolving" whois servers. Clients who don't care about data origin shouldn't be interested in origin-specific extensions anyway. A meaningful prefix is a favor that designers do to interested clients, syntactic sugar that reminds the scope of a name. > There are two ways to obtain uniqueness of identifiers: structured names > or a registry. Take your pick. > > However this may all be a moot point if extensibility isn't needed so > perhaps the WG should have consensus on that point first. While we don't want to specify attributes like beforeOneSmallStep now, as time goes by more and more registries may find it useful to use it. Instead of having lunarNic_beforeOneSmallStep, marsNic_beforeOneSmallStep, denebianNIC_beforeOneSmallStep, etcetera, it will be handier to specify that attribute once and for all. If that's going to happen frequently, IMHO a registry is better than long chains of "updated by" RFCs. jm2c From Ray.Bellis@nominet.org.uk Mon Jun 18 02:45:32 2012 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 E870D21F859B for ; Mon, 18 Jun 2012 02:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNw5BOhaW86W for ; Mon, 18 Jun 2012 02:45:32 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0B60C21F8551 for ; Mon, 18 Jun 2012 02:45:31 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=ig+eIq2FKK0K3t5B2vKqfwlUJh2oGuu+1zx7bj+caFHwV55bwL5y1Pr8 0ryokTms/bzAJoQBd1tJVfNIblPiEpyBzgTIJEu8XJ8TI4ddW0P0zpocB JzW/sp4oLjIZULW; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1340012732; x=1371548732; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[weirds]=20JSON=20naming|Date:=20Mon, =2018=20Jun=202012=2009:45:29=20+0000|Message-ID:=20<005D E8AA-5564-4638-9E31-AA185695EDD2@nominet.org.uk>|To:=20Le if=20Johansson=20|CC:=20"weirds@ietf.org" =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<1455ffd8-e205-45ea-9bf5-e16b5b043e58> |In-Reply-To:=20<4FDCFE89.7090409@mnt.se>|References:=20< 855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net>=0D=0A=20<4 FDB441E.4000001@mnt.se>=0D=0A=20=0D=0A=20<4FDC FE89.7090409@mnt.se>; bh=IdHNlw53Zpfpuhqj2sWRx1dI3pg9nApxm5INeShUZ54=; b=sgZpSiMAgl3OQxk1sazA3qrpQboSY+oh4MrV73EV3RcN1njpMGu4JxLE BPsO6Tn3M2JddF2kHUhfEbJ0sLXsIiVtefqYbNj9Zk15tqmquSn2hQEz8 WP8D7xHy1YE5OMo; X-IronPort-AV: E=Sophos;i="4.77,430,1336345200"; d="scan'208";a="40974860" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 18 Jun 2012 10:45:29 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Mon, 18 Jun 2012 10:45:29 +0100 From: Ray Bellis To: Leif Johansson Thread-Topic: [weirds] JSON naming Thread-Index: AQHNSwG1NgPw+dFiwUi8eFvTWgkHQZb8N72AgAE0QICAAltsgA== Date: Mon, 18 Jun 2012 09:45:29 +0000 Message-ID: <005DE8AA-5564-4638-9E31-AA185695EDD2@nominet.org.uk> References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> <4FDCFE89.7090409@mnt.se> In-Reply-To: <4FDCFE89.7090409@mnt.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <1455ffd8-e205-45ea-9bf5-e16b5b043e58> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] JSON naming 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, 18 Jun 2012 09:45:33 -0000 On 16 Jun 2012, at 22:45, Leif Johansson wrote: > Being a coder myself (at least sometimes) I know that ':' in > strings isn't an issue. Indeed not, although it should be noted that within JS at least, a key with= a ":" in it must be accessed as: obj["some:key"] rather than: obj.somekey This also means that JS debuggers will refuse to autocomplete any such prop= erty - keys that aren't legal tokens don't appear in the autocompletion lis= t. In other words, ":" works, but isn't IMHO "programmer friendly". kind regards, Ray From leifj@mnt.se Mon Jun 18 02:48:01 2012 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 530D921F8551 for ; Mon, 18 Jun 2012 02:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_37=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 JXrJIWhLkKR5 for ; Mon, 18 Jun 2012 02:48:00 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 400F921F854E for ; Mon, 18 Jun 2012 02:47:59 -0700 (PDT) Received: from [109.105.104.174] (dhcp40.se-tug.nordu.net [109.105.104.174] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5I9ltol000633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 11:47:58 +0200 (CEST) Message-ID: <4FDEF94B.1090208@mnt.se> Date: Mon, 18 Jun 2012 11:47:55 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ray Bellis References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> <4FDCFE89.7090409@mnt.se> <005DE8AA-5564-4638-9E31-AA185695EDD2@nominet.org.uk> In-Reply-To: <005DE8AA-5564-4638-9E31-AA185695EDD2@nominet.org.uk> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "weirds@ietf.org" Subject: Re: [weirds] JSON naming 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, 18 Jun 2012 09:48:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2012 11:45 AM, Ray Bellis wrote: > > On 16 Jun 2012, at 22:45, Leif Johansson wrote: > >> Being a coder myself (at least sometimes) I know that ':' in >> strings isn't an issue. > > Indeed not, although it should be noted that within JS at least, a > key with a ":" in it must be accessed as: > > obj["some:key"] > > rather than: > > obj.somekey > > This also means that JS debuggers will refuse to autocomplete any > such property - keys that aren't legal tokens don't appear in the > autocompletion list. > > In other words, ":" works, but isn't IMHO "programmer friendly". > > kind regards, > > Ray > OK so pick some transposition then. It really doesn't matter. My point was (and is) that if all you restrict yourself to "flat" names then you either do extensions as specs or run a registry or you'll have implementations allocate the same "private" name for different purposes. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/e+UsACgkQ8Jx8FtbMZnfQAQCfWBkCG+LSMW7xsJT3RyHhJrvp q24An0s6d6bbkTF6O8gTal+xDg9tgIfK =Z0W0 -----END PGP SIGNATURE----- From leifj@mnt.se Mon Jun 18 02:48:06 2012 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 DEF7A21F859B for ; Mon, 18 Jun 2012 02:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp8Loezdl46I for ; Mon, 18 Jun 2012 02:48:06 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 2382021F8599 for ; Mon, 18 Jun 2012 02:48:05 -0700 (PDT) Received: from [109.105.104.174] (dhcp40.se-tug.nordu.net [109.105.104.174] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5I9gjsj023349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 11:42:48 +0200 (CEST) Message-ID: <4FDEF815.9060202@mnt.se> Date: Mon, 18 Jun 2012 11:42:45 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120617152708.34963.qmail@joyce.lan> <4FDE2776.60809@mnt.se> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] JSON naming 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, 18 Jun 2012 09:48:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2012 10:33 AM, Murray S. Kucherawy wrote: > On Sun, Jun 17, 2012 at 11:00 PM, Dave Piscitello > > > wrote: > > I don't see how john's vision excludes extensibility > > > > Indeed, the "E" in "WEIRDS" stands for "extensible". > > -MSK > So in that case some thought needs to be spent on how to manage JSON names. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/e+BUACgkQ8Jx8FtbMZndQLwCfWDpJiWyVa2TRwQXRmi6mTkc3 1FkAnA1KughWl2w5kqKc5DdCHeGvAVhF =wUdN -----END PGP SIGNATURE----- From alexandrsergeyev@gmail.com Mon Jun 18 03:50:22 2012 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 6E23B21F8599 for ; Mon, 18 Jun 2012 03:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p6eSACuiFHV for ; Mon, 18 Jun 2012 03:50:22 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id A436F21F8593 for ; Mon, 18 Jun 2012 03:50:21 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so1506994wgb.1 for ; Mon, 18 Jun 2012 03:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=PqeHADwyz67Lx/SekuF4AHwr92skTZtrIc2KTmVh2Ao=; b=pJ5pXuP9Giua1iGcH/f3O02rr7EcK8gliSei4wg5J5207DXjKikJMpihszSmLPA1kJ jJKeEsT0sQJyf4++1YGfU+VumjQFxcc7Oosy7EfyNAn41pJ2iKh760+Tqq7EKpPRpu3c jNMPrOb2DJIee0I60mZB/ssBILwIxDEOiD+AlyS+jHXJUbmTCb33Z+bG3hXA343sg/y3 6TObzKWOLhfjKlgdVFUf4AyfCvVMAZJwYEd3UqUni/893xiSDaA0EjhJxgGyGrlVs7pV /TrBpm6qYUiknhSq1sjaHdapdchktgPtimgf3Q7oUzrv+1qO60os0uB5qnOyx2NjQdcI 1tjQ== MIME-Version: 1.0 Received: by 10.180.14.34 with SMTP id m2mr23129923wic.22.1340016620545; Mon, 18 Jun 2012 03:50:20 -0700 (PDT) Sender: alexandrsergeyev@gmail.com Received: by 10.216.49.16 with HTTP; Mon, 18 Jun 2012 03:50:20 -0700 (PDT) In-Reply-To: <4FDEF815.9060202@mnt.se> References: <20120617152708.34963.qmail@joyce.lan> <4FDE2776.60809@mnt.se> <4FDEF815.9060202@mnt.se> Date: Mon, 18 Jun 2012 06:50:20 -0400 X-Google-Sender-Auth: ql1nTpTKm71fBUQndqKUK3P6a7c Message-ID: From: Alex Sergeyev To: Leif Johansson , weirds@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [weirds] JSON naming 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, 18 Jun 2012 10:50:22 -0000 Leif, >> Indeed, the "E" in "WEIRDS" stands for "extensible". > So in that case some thought needs to be spent on how to > manage JSON names. Your assumption is "common sense is not enough" which could be true but not for prevailing number of registries. I was working on toy-implementation of WEIRDS for Dyn and found following kinds of extension that we needed: 1. New types of objects. For example, dynamic DNS hosts, registered by our clients in our zones it's easy, just maintain another /objectclass/id and send info from there. Most of the fields are "new to weirds" but still resemble domains. Do you think this kind of extension requires some sort of non-flat naming then? It will look ugly and has no practicality in terms of "making someone's life easier." 2. Adding new info to domain name information. One thing I did to add pointer to "Dyn User" account is to "extend" contacts and put it there (detailed information will be not accessible for public-facing weirds) Again, because of kind of information, it was logical to add this to domain "contacts" as "dynuser" (and this is preliminary name for sure). Both decisions were made assuming that "things that clients will not use are going to be ignored". If someone comes to us for info on domain after referral from Verisign registry, they won't care about "dynuser" anyway. In case if they have client for OUR service, they will read all fields. What would you do differently? What other extensions you see that would be hard or wrong to do with flat naming? Look at this other way.... Say you have WEIRDS client and you see our fields (assume we'll add 10 more) as "unrecognized". Would that bother you? Is ":" solving a problem at al? How? -- Alex. From leifj@mnt.se Mon Jun 18 05:46:36 2012 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 7526D21F866E for ; Mon, 18 Jun 2012 05:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 5qx4uaWYFJ0y for ; Mon, 18 Jun 2012 05:46:35 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 39A3F21F8682 for ; Mon, 18 Jun 2012 05:46:35 -0700 (PDT) Received: from [172.20.10.2] (2.64.253.83.mobile.tre.se [2.64.253.83]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5ICkP8D005396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 14:46:29 +0200 (CEST) Message-ID: <4FDF2321.3090102@mnt.se> Date: Mon, 18 Jun 2012 14:46:25 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alex Sergeyev References: <20120617152708.34963.qmail@joyce.lan> <4FDE2776.60809@mnt.se> <4FDEF815.9060202@mnt.se> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] JSON naming 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, 18 Jun 2012 12:46:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2012 12:50 PM, Alex Sergeyev wrote: > Leif, > >>> Indeed, the "E" in "WEIRDS" stands for "extensible". > >> So in that case some thought needs to be spent on how to manage >> JSON names. > > Your assumption is "common sense is not enough" which could be > true but not for prevailing number of registries. You need common sense in combination with coordination which sorta spells like a registry to me :-) > > I was working on toy-implementation of WEIRDS for Dyn and found > following kinds of extension that we needed: > > 1. New types of objects. For example, dynamic DNS hosts, registered > by our clients in our zones > > it's easy, just maintain another /objectclass/id and send info from > there. Most of the fields are "new to weirds" but still resemble > domains. > > Do you think this kind of extension requires some sort of non-flat > naming then? It will look ugly and has no practicality in terms of > "making someone's life easier." > > > 2. Adding new info to domain name information. > > One thing I did to add pointer to "Dyn User" account is to "extend" > contacts and put it there (detailed information will be not > accessible for public-facing weirds) > > Again, because of kind of information, it was logical to add this > to domain "contacts" as "dynuser" (and this is preliminary name for > sure). > > > Both decisions were made assuming that "things that clients will > not use are going to be ignored". > > If someone comes to us for info on domain after referral from > Verisign registry, they won't care about "dynuser" anyway. In case > if they have client for OUR service, they will read all fields. Thats fine unless Verising decide to use 'dynuser' for something completely different. MVH leifj -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fIyEACgkQ8Jx8FtbMZnfLrwCgr2PQrJcTr45jmOMQXxKwFtfl N80AmgLUaRl0AXr/sspO7OHlkeSHvT8y =A6Ar -----END PGP SIGNATURE----- From johnl@iecc.com Mon Jun 18 06:20:58 2012 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 CB7BD21F85D1 for ; Mon, 18 Jun 2012 06:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.916 X-Spam-Level: X-Spam-Status: No, score=-110.916 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWJYgKnB-XwS for ; Mon, 18 Jun 2012 06:20:58 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 2342121F85C7 for ; Mon, 18 Jun 2012 06:20:57 -0700 (PDT) Received: (qmail 57457 invoked from network); 18 Jun 2012 13:20:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Jun 2012 13:20:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fdf2b38.xn--hew.k1206; i=johnl@user.iecc.com; bh=fiQEFw73HCVPEzRIH5o2eoBSByGBfBlGhwUT90I8O64=; b=QlRgetbVK6oajeFy9bFgbBQNLMt1EUK9WLHIqqmxA2lBkxmw0J7/R5vk2hEn2UcWQuh4vlEK7sb7rhrOrLsx7Sb5x28qyzxUXeZxwnSy+TVhK1nhOf0LIyrfBJHohKF673hFoLR/8BSi8rG8KjHrco4gH4n7vuOJIt+DD43zhlc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Jun 2012 13:20:34 -0000 Message-ID: <20120618132034.56471.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <4FDEC615.70401@mnt.se> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 13:20:58 -0000 >Joe Levine seems to say that extensibility isn't necessarily in scope >for weirds. If so then the issues we discuss in this thread are of no >consequence to weirds and we can just stop this thread :-) Well, other than that's not what I said and my name isn't Joe, OK. The question of how one extends a standard is not exactly unprecedented in the IETF. If anyone can add any extensions they want, even if there's a registry to avoid name collisions, you end up with a mess that doesn't interoperate. You'll have a dozen different names for more or less the same thing, with slightly different syntax and meaning. The current plan is to come up with one or two RFCs that describe the query and response formats, including all the fields. Anyone who wants to interoperate (which, I hope everyone remembers, is the point of a standard) will implement those. The usual approach in situations like this is to have a registry, but only permit updates via new RFCs. In the IETF, to add extensions, you write an Internet Draft, not necessarily in a working group, run it through a review process, and have it published as an RFC which updates the registry. We do this all the time. It allows reasonable extensions, while keeping the chaos under control. If you think you have a private extension that nobody else will ever use, ever, go ahead and invent a private name for it, but I can assure you from long experience that those "private" extensions often end up as undocumented de-facto exensions that don't interoperate very well. We know how to do it right, so please don't ask us to do it wrong. R's, John From peter@denic.de Mon Jun 18 07:43:42 2012 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 67F0B21F86B2 for ; Mon, 18 Jun 2012 07:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-FK0kIpaNeu for ; Mon, 18 Jun 2012 07:43:41 -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 BA4B621F8690 for ; Mon, 18 Jun 2012 07:43:41 -0700 (PDT) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1SgdB6-00073G-5G; Mon, 18 Jun 2012 16:43:40 +0200 Received: from localhost by x27.adm.denic.de with local id 1SgdB6-00023t-1Y; Mon, 18 Jun 2012 16:43:40 +0200 Date: Mon, 18 Jun 2012 16:43:40 +0200 From: Peter Koch To: weirds@ietf.org Message-ID: <20120618144340.GS10866@x27.adm.denic.de> Mail-Followup-To: weirds@ietf.org References: <4FDEC615.70401@mnt.se> <20120618132034.56471.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120618132034.56471.qmail@joyce.lan> User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 14:43:42 -0000 On Mon, Jun 18, 2012 at 01:20:34PM +0000, John Levine wrote: > The usual approach in situations like this is to have a registry, but only > permit updates via new RFCs. not sure whether you mentioned this as an example or as a proposal to go for "RFC required" ... > In the IETF, to add extensions, you write an Internet Draft, not > necessarily in a working group, run it through a review process, and > have it published as an RFC which updates the registry. We do this all ... or "IETF Review" as per RFC 5226. > the time. It allows reasonable extensions, while keeping the chaos > under control. My reading of the emerging or current spirit in the apps area (probably influenced by communities which have, say, different, approaches to what standards are for) is that this intention might see significant pushback. There is increasing reluctance to use the standardization process as either a quality gate or an architectural oversight tool. Sadly so, one might say. -Peter From leifj@mnt.se Mon Jun 18 08:18:54 2012 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 CE85821F8516 for ; Mon, 18 Jun 2012 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 a7cmjB51tQ3B for ; Mon, 18 Jun 2012 08:18:53 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 227D421F85D0 for ; Mon, 18 Jun 2012 08:18:52 -0700 (PDT) Received: from [192.36.125.244] (dhcp.pilsnet.sunet.se [192.36.125.244] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5IFIiiD022377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 17:18:47 +0200 (CEST) Message-ID: <4FDF46D4.7010908@mnt.se> Date: Mon, 18 Jun 2012 17:18:44 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Levine References: <20120618132034.56471.qmail@joyce.lan> In-Reply-To: <20120618132034.56471.qmail@joyce.lan> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 15:18:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2012 03:20 PM, John Levine wrote: > Well, other than that's not what I said and my name isn't Joe, OK. Darnit. sorry, I had a feeling there was something wrong there... :-( -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fRtAACgkQ8Jx8FtbMZnejZQCgo2CYyEnp5JFHTczqrsT0ifVm 3hcAnAq/GyGOuSEjFRCC7xuKoR1ztqDp =/R6Y -----END PGP SIGNATURE----- From leifj@mnt.se Mon Jun 18 08:25:43 2012 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 F323921F8734 for ; Mon, 18 Jun 2012 08:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 sFhf5qg2i1hz for ; Mon, 18 Jun 2012 08:25:42 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id DB10221F8554 for ; Mon, 18 Jun 2012 08:25:41 -0700 (PDT) Received: from [192.36.125.244] (dhcp.pilsnet.sunet.se [192.36.125.244] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5IFPaOe019354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jun 2012 17:25:39 +0200 (CEST) Message-ID: <4FDF4870.2020301@mnt.se> Date: Mon, 18 Jun 2012 17:25:36 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Levine References: <20120618132034.56471.qmail@joyce.lan> In-Reply-To: <20120618132034.56471.qmail@joyce.lan> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: weirds@ietf.org Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 15:25:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The usual approach in situations like this is to have a registry, > but only permit updates via new RFCs. I think that is one very reasonable approach. My original email served to illustrate another approach and then we got bogged down in ':'ology. Sorry about that... > > In the IETF, to add extensions, you write an Internet Draft, not > necessarily in a working group, run it through a review process, > and have it published as an RFC which updates the registry. We do > this all the time. It allows reasonable extensions, while keeping > the chaos under control. There are several other processes to choose from when setting up an IANA registry as I think you know. Depending (in the case of weirds) how names are allocated, not all extensions need be subject to IESG review or even publication as RFC. > > If you think you have a private extension that nobody else will > ever use, ever, go ahead and invent a private name for it, but I > can assure you from long experience that those "private" extensions > often end up as undocumented de-facto exensions that don't > interoperate very well. > Which is why I was arguing for some coordination or structure around so called private extensions. > We know how to do it right, so please don't ask us to do it wrong. Thank you for putting it succinctly. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fSHAACgkQ8Jx8FtbMZnc1sgCgqkBM9X0Y3xd5WSQoWLtPJykn HzoAn3KwUgCVWyAXnzxEH/MBZspD99lK =MHNk -----END PGP SIGNATURE----- From leifj@mnt.se Mon Jun 18 08:26:37 2012 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 A2AC721F85D6 for ; Mon, 18 Jun 2012 08:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.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 MwfaqnCm1rtM for ; Mon, 18 Jun 2012 08:26:37 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id CBFA121F8554 for ; Mon, 18 Jun 2012 08:26:36 -0700 (PDT) Received: from [192.36.125.244] (dhcp.pilsnet.sunet.se [192.36.125.244] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5IFQX5Z018224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jun 2012 17:26:36 +0200 (CEST) Message-ID: <4FDF48A9.9090309@mnt.se> Date: Mon, 18 Jun 2012 17:26:33 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <4FDEC615.70401@mnt.se> <20120618132034.56471.qmail@joyce.lan> <20120618144340.GS10866@x27.adm.denic.de> In-Reply-To: <20120618144340.GS10866@x27.adm.denic.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 15:26:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2012 04:43 PM, Peter Koch wrote: > On Mon, Jun 18, 2012 at 01:20:34PM +0000, John Levine wrote: > >> The usual approach in situations like this is to have a registry, >> but only permit updates via new RFCs. > > not sure whether you mentioned this as an example or as a proposal > to go for "RFC required" ... > >> In the IETF, to add extensions, you write an Internet Draft, not >> necessarily in a working group, run it through a review process, >> and have it published as an RFC which updates the registry. We >> do this all > > ... or "IETF Review" as per RFC 5226. > >> the time. It allows reasonable extensions, while keeping the >> chaos under control. > > My reading of the emerging or current spirit in the apps area > (probably influenced by communities which have, say, different, > approaches to what standards are for) is that this intention might > see significant pushback. There is increasing reluctance to use > the standardization process as either a quality gate or an > architectural oversight tool. Sadly so, one might say. Exactly my point. Thx. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fSKkACgkQ8Jx8FtbMZneLWwCgjadYkd6/frIrtC8nth2cmvoK lQYAnRTrjIm7J6boBeK5kuNglkMoBqJt =IYKJ -----END PGP SIGNATURE----- From johnl@iecc.com Mon Jun 18 08:44:33 2012 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 184BC21F8700 for ; Mon, 18 Jun 2012 08:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDBnFBwYpURv for ; Mon, 18 Jun 2012 08:44:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1221F86BA for ; Mon, 18 Jun 2012 08:44:31 -0700 (PDT) Received: (qmail 3974 invoked from network); 18 Jun 2012 15:44:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=f85.4fdf4cdd.k1206; bh=6UHXThawcg7PhEYxMH6VVuMdrE11jEdd9fpEsB1LvQ0=; b=lcHeGAtX0KCOgJEH2ymqQeBo7c6bkcmuS2B4ZayZUVb58WM5o9t6xFVGB7uHr02mY6Qa+p8oSoTszC1vyR/tVSU3xEKOxJc31sUMuM8N1n1T8i/7k5Rz2ZD/H/f9E52oQ8SmazDvC4gEY9DyD+lza29TugyYDQeYPDnpqiA+hkA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 18 Jun 2012 15:44:07 -0000 Date: 18 Jun 2012 11:44:29 -0400 Message-ID: From: "John R. Levine" To: weirds@ietf.org User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 15:44:33 -0000 >> The usual approach in situations like this is to have a registry, but only >> permit updates via new RFCs. > >not sure whether you mentioned this as an example or as a proposal >to go for "RFC required" ... I suppose it's a proposal. Makes sense to me. I wouldn't be unalterably opposed to expert review, but the RFC requirement means that there's a stable description of the extension. >My reading of the emerging or current spirit in the apps area (probably >influenced by communities which have, say, different, approaches to >what standards are for) is that this intention might see significant >pushback. There is increasing reluctance to use the standardization >process as either a quality gate or an architectural oversight tool. >Sadly so, one might say. Depends where. Over in the world of e-mail, we think that RFC required is quite reasonable if you want to add an option to SMTP or define a new mail header. And this is so even though in both cases we have well developed ways to ignore extensions an implementation doesn't understand. I recently did new MIME types for application/gzip and application/zlib via a non-WG RFC and expert review (about 15 years overdue, but better late than never.) It wasn't an unreasonable amount of work. The RFC is currently in the editor's queue and should be out soon. The review process for the RFC definitely made the spec better. R's, John From ajs@anvilwalrusden.com Mon Jun 18 08:54:42 2012 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 7CF7A21F85A5 for ; Mon, 18 Jun 2012 08:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 4AeDRBr-Wxfa for ; Mon, 18 Jun 2012 08:54:41 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9602521F858D for ; Mon, 18 Jun 2012 08:54:41 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 451C41ECB41D for ; Mon, 18 Jun 2012 15:54:40 +0000 (UTC) Date: Mon, 18 Jun 2012 11:54:42 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120618155442.GE32683@mail.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 15:54:42 -0000 On Mon, Jun 18, 2012 at 11:44:29AM -0400, John R. Levine wrote: > > I suppose it's a proposal. Makes sense to me. I wouldn't be unalterably > opposed to expert review, but the RFC requirement means that there's a > stable description of the extension. I am opposed to it. If we need a registry (and I still have my doubts, although I am somewhat more persuaded by the latest arguments I've seen) what is wrong with FCFS? We are not the Internet Cops. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From leifj@mnt.se Mon Jun 18 09:04:53 2012 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 E94D021F86EE for ; Mon, 18 Jun 2012 09:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 H6w+3iPiDeGB for ; Mon, 18 Jun 2012 09:04:53 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id C555221F86DF for ; Mon, 18 Jun 2012 09:04:52 -0700 (PDT) Received: from [192.36.125.244] (dhcp.pilsnet.sunet.se [192.36.125.244] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5IG4lcT011969 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jun 2012 18:04:50 +0200 (CEST) Message-ID: <4FDF519E.1000205@mnt.se> Date: Mon, 18 Jun 2012 18:04:46 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <20120618155442.GE32683@mail.yitter.info> In-Reply-To: <20120618155442.GE32683@mail.yitter.info> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 16:04:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2012 05:54 PM, Andrew Sullivan wrote: > On Mon, Jun 18, 2012 at 11:44:29AM -0400, John R. Levine wrote: >> >> I suppose it's a proposal. Makes sense to me. I wouldn't be >> unalterably opposed to expert review, but the RFC requirement >> means that there's a stable description of the extension. > > I am opposed to it. If we need a registry (and I still have my > doubts, although I am somewhat more persuaded by the latest > arguments I've seen) what is wrong with FCFS? We are not the > Internet Cops. I'd go for expert review with a review policy that is explicitly permissive: your only goal is to keep nuisance-registrations out. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fUZ4ACgkQ8Jx8FtbMZncfYwCfS07cljyo2Ud+iQ2fx1mH1567 ACIAoIZKRFwMw1O51kq7Lt0E7HKAXFjx =Ud5m -----END PGP SIGNATURE----- From andy@arin.net Mon Jun 18 09:13:20 2012 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 22C5121F86B1 for ; Mon, 18 Jun 2012 09:13:20 -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 dthfL9CLW4+C for ; Mon, 18 Jun 2012 09:13:19 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 53AE521F8692 for ; Mon, 18 Jun 2012 09:13:19 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 2C5CC165048; Mon, 18 Jun 2012 12:12:57 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 9632C165062; Mon, 18 Jun 2012 12:12:55 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 18 Jun 2012 12:12:49 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.4]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0247.003; Mon, 18 Jun 2012 12:12:54 -0400 From: Andy Newton To: Andrew Sullivan Thread-Topic: [weirds] extensibility in weirds Thread-Index: AQHNTWk/QIAMZqaIekq+Q5M9B5uKv5cAfZQAgAAFFYA= Date: Mon, 18 Jun 2012 16:12:53 +0000 Message-ID: References: <20120618155442.GE32683@mail.yitter.info> In-Reply-To: <20120618155442.GE32683@mail.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <7EB46C1B389CFD438A8C3AB741ED118D@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 16:13:20 -0000 On Jun 18, 2012, at 11:54 AM, Andrew Sullivan wrote: > On Mon, Jun 18, 2012 at 11:44:29AM -0400, John R. Levine wrote: >>=20 >> I suppose it's a proposal. Makes sense to me. I wouldn't be unalterabl= y >> opposed to expert review, but the RFC requirement means that there's a >> stable description of the extension. >=20 > I am opposed to it. If we need a registry (and I still have my > doubts, although I am somewhat more persuaded by the latest arguments > I've seen) what is wrong with FCFS? We are not the Internet Cops. By FCFS, do you mean first come, first served? Do we have a real concern th= at multiple registries are gonna rush to register the "lunarNic" prefix? I'm not exactly a huge fan of the registry idea, though I understand the ne= ed. To me an independent submission of an informational does not seem to be= that big of a hill to climb, but I'm also somewhat familiar with IETF proc= ess. Perhaps this is where we can leverage experience with EPP. Are there EPP ex= tensions out there that are not documented with RFCs? And if so, was the RF= C process considered too onerous or were the EPP implementers simply unawar= e of the RFC process? -andy= From leifj@mnt.se Mon Jun 18 09:28:15 2012 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 21FBD21F86D5 for ; Mon, 18 Jun 2012 09:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 VY8Q3amqU4Dv for ; Mon, 18 Jun 2012 09:28:14 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id ED0A021F86D4 for ; Mon, 18 Jun 2012 09:28:13 -0700 (PDT) Received: from [192.36.125.244] (dhcp.pilsnet.sunet.se [192.36.125.244] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5IGSAm2015576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jun 2012 18:28:13 +0200 (CEST) Message-ID: <4FDF571A.3010703@mnt.se> Date: Mon, 18 Jun 2012 18:28:10 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <20120618155442.GE32683@mail.yitter.info> In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 16:28:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Perhaps this is where we can leverage experience with EPP. Are > there EPP extensions out there that are not documented with RFCs? > And if so, was the RFC process considered too onerous or were the > EPP implementers simply unaware of the RFC process? Could be this changes somewhat as coding up something in JSON is (intentionally) easier to do... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fVxoACgkQ8Jx8FtbMZndpAQCfUI/OPkVFzq5x2jnuNT2CDPdH 2TgAn0TMaWiX//crfOZnfK/gt+XF6V5z =8bym -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Mon Jun 18 10:05:09 2012 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 CA77C21F86EF for ; Mon, 18 Jun 2012 10:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3ITnFOJ5JNu for ; Mon, 18 Jun 2012 10:05:09 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5199B21F86EA for ; Mon, 18 Jun 2012 10:05:09 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 39BA91ECB41D for ; Mon, 18 Jun 2012 17:05:08 +0000 (UTC) Date: Mon, 18 Jun 2012 13:05:06 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120618170506.GH32683@mail.yitter.info> References: <20120618155442.GE32683@mail.yitter.info> <4FDF519E.1000205@mnt.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FDF519E.1000205@mnt.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 17:05:09 -0000 On Mon, Jun 18, 2012 at 06:04:46PM +0200, Leif Johansson wrote: > I'd go for expert review with a review policy that is explicitly > permissive: your only goal is to keep nuisance-registrations out. I'm the co-ordinator of expert reviews for DNS RRTYPE numbers. We've had a large number of process failures almost all of which has resulted from experts just not completing things on time. Why do we think this community would be more likely to have experts with a lot of extra time to devote to this? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Mon Jun 18 10:08:39 2012 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 9D04421F8624 for ; Mon, 18 Jun 2012 10:08: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 Q21xS1y83Iv0 for ; Mon, 18 Jun 2012 10:08:39 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 14FBA21F85E1 for ; Mon, 18 Jun 2012 10:08:39 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 723841ECB420 for ; Mon, 18 Jun 2012 17:08:38 +0000 (UTC) Date: Mon, 18 Jun 2012 13:08:36 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120618170836.GJ32683@mail.yitter.info> References: <20120618155442.GE32683@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 17:08:39 -0000 On Mon, Jun 18, 2012 at 04:12:53PM +0000, Andy Newton wrote: > > Perhaps this is where we can leverage experience with EPP. Are there EPP extensions out there that are not documented with RFCs? And if so, was the RFC process considered too onerous or were the EPP implementers simply unaware of the RFC process? > There are indeed such extensions. Most of them, last I heard. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From jaap@NLnetLabs.nl Mon Jun 18 10:40:02 2012 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 AACE821F86C1 for ; Mon, 18 Jun 2012 10:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSgVVIhpkAkf for ; Mon, 18 Jun 2012 10:40:01 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by ietfa.amsl.com (Postfix) with ESMTP id 7455C21F86B4 for ; Mon, 18 Jun 2012 10:40:01 -0700 (PDT) Received: from NLnetLabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id q5IHdw2w013734 for ; Mon, 18 Jun 2012 19:39:58 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) X-DKIM: OpenDKIM Filter v2.5.2 bartok.nlnetlabs.nl q5IHdw2w013734 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=sleutel; t=1340041199; bh=1EbrT9Mg/McdXCZ7vLUCevC0FFFVEt322IBniKAHVMg=; h=To:Subject:In-reply-to:References:Date:From; b=b40QCzOMxRYP4xim7eNwMt212sNpJSPIPwrK0JNjVCB911w0HWymKCvcsa23OiG+1 PK+G3CVH+3/6zQKBjkHaA50Ca0ysTxxO90+jO9HWBXUzxtwtwuWBwY6hAUu2xLV+oN +NLd36y+mGYSvFItXQ+d+2tCxRIYEnkF7bh++9Cg= Message-Id: <201206181739.q5IHdw2w013734@bartok.nlnetlabs.nl> To: weirds@ietf.org In-reply-to: <4FDF571A.3010703@mnt.se> References: <20120618155442.GE32683@mail.yitter.info> <4FDF571A.3010703@mnt.se> Comments: In-reply-to Leif Johansson message dated "Mon, 18 Jun 2012 18:28:10 +0200." Date: Mon, 18 Jun 2012 19:39:58 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bartok.nlnetlabs.nl [127.0.0.1]); Mon, 18 Jun 2012 19:39:58 +0200 (CEST) Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 17:40:02 -0000 Leif Johansson leifj@mnt.se>: > Perhaps this is where we can leverage experience with EPP. Are > there EPP extensions out there that are not documented with RFCs? AFAIK, there is hardly any extension documented in an RFC. > And if so, was the RFC process considered too onerous or were the > EPP implementers simply unaware of the RFC process? Lazyness is probably a major reason. jaap From shollenbeck@verisign.com Mon Jun 18 10:55:01 2012 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 F169721F86D5 for ; Mon, 18 Jun 2012 10:55:00 -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 aB7uYs7wI7n7 for ; Mon, 18 Jun 2012 10:54:59 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id BCB7221F86E0 for ; Mon, 18 Jun 2012 10:54:56 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKT99rcLgVBJlinFYVIWCkaaipvouRR11x@postini.com; Mon, 18 Jun 2012 10:54:59 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q5IHsqrm020301 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jun 2012 13:54:52 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 18 Jun 2012 13:54:52 -0400 From: "Hollenbeck, Scott" To: Jaap Akkerhuis , "weirds@ietf.org" Thread-Topic: [weirds] extensibility in weirds Thread-Index: AQHNTXlzjHr+HgPstE6DmlLAVCjvKJcAWcyw Date: Mon, 18 Jun 2012 17:54:52 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D61C880@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20120618155442.GE32683@mail.yitter.info> <4FDF571A.3010703@mnt.se> <201206181739.q5IHdw2w013734@bartok.nlnetlabs.nl> In-Reply-To: <201206181739.q5IHdw2w013734@bartok.nlnetlabs.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 17:55:01 -0000 > -----Original Message----- > From: weirds-bounces@ietf.org [mailto:weirds-bounces@ietf.org] On > Behalf Of Jaap Akkerhuis > Sent: Monday, June 18, 2012 1:40 PM > To: weirds@ietf.org > Subject: Re: [weirds] extensibility in weirds >=20 >=20 >=20 > Leif Johansson leifj@mnt.se>: > > Perhaps this is where we can leverage experience with EPP. Are > > there EPP extensions out there that are not documented with RFCs? >=20 > AFAIK, there is hardly any extension documented in an RFC. Extension RFCs: http://datatracker.ietf.org/doc/rfc3915/ http://datatracker.ietf.org/doc/rfc4114/ http://datatracker.ietf.org/doc/rfc4310/ (obsolete by 5910) http://datatracker.ietf.org/doc/rfc5076/ http://datatracker.ietf.org/doc/rfc5910/ Extension I-Ds: http://datatracker.ietf.org/doc/draft-kong-epp-idn-variants-mapping/ http://datatracker.ietf.org/doc/draft-obispo-epp-idn/ Scott From andy@hxr.us Mon Jun 18 11:19:53 2012 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 0AE9221F86D5 for ; Mon, 18 Jun 2012 11:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz8GWsDcj-xJ for ; Mon, 18 Jun 2012 11:19:52 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F46C21F86C1 for ; Mon, 18 Jun 2012 11:19:52 -0700 (PDT) Received: by yhq56 with SMTP id 56so4487605yhq.31 for ; Mon, 18 Jun 2012 11:19:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=SmBwQd/nZxXTT6C0VXoWLDRtjRXBXtBoHw88TDR6118=; b=pL26P1mImr0EWu1iN52OVyeswDkwvsfC7kFBk9aDp5RIh17DBIdHNMIB0s7wu9ALJr JCEhchXKJ6uISFPLhBvQU92kTQKOa06AFaTmtKt4i0V/0jOTKkwVtED7DobgIBI7kUlH 6kwe3hUjga3hTwdmtooWk5a+F5uCw5JCSUSM/fQNnFxJWGaNnBFVKWWL6gTjGUxMXcv8 OFqV+JIO0MaKc/vvDrpY4PGYcU1TaEYeeM7nvXnD01I+PlWHET8c0rI2iUjmyTLDDaMT mTOCEY5wHrrrtqLcekc1g9Y7zMF21QzcyGfyWGgjQ0gDwmAORENztluaQmWv+voNKwo1 CrrA== Received: by 10.236.197.8 with SMTP id s8mr20120865yhn.9.1340043591922; Mon, 18 Jun 2012 11:19:51 -0700 (PDT) Received: from ?IPv6:2001:500:4:15:8018:9056:9667:f8ff? ([2001:500:4:15:8018:9056:9667:f8ff]) by mx.google.com with ESMTPS id f8sm26362198anm.16.2012.06.18.11.19.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jun 2012 11:19:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Andy Newton In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F0D61C880@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Mon, 18 Jun 2012 14:19:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1512BAB3-3855-45C5-9F53-C4A02AB669A3@hxr.us> References: <20120618155442.GE32683@mail.yitter.info> <4FDF571A.3010703@mnt.se> <201206181739.q5IHdw2w013734@bartok.nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F0D61C880@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQnq14tmtdClJWIcVdpT+hw09cX1RXyag4RzSiBV5kv608oDvt9vOAjSlq7Ev7L4/FfXFwJa Cc: "weirds@ietf.org" Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 18:19:53 -0000 On Jun 18, 2012, at 1:54 PM, Hollenbeck, Scott wrote: >> AFAIK, there is hardly any extension documented in an RFC. >=20 > Extension RFCs: >=20 > http://datatracker.ietf.org/doc/rfc3915/ >=20 > http://datatracker.ietf.org/doc/rfc4114/ >=20 > http://datatracker.ietf.org/doc/rfc4310/ > (obsolete by 5910) >=20 > http://datatracker.ietf.org/doc/rfc5076/ >=20 > http://datatracker.ietf.org/doc/rfc5910/ >=20 > Extension I-Ds: >=20 > http://datatracker.ietf.org/doc/draft-kong-epp-idn-variants-mapping/ >=20 > http://datatracker.ietf.org/doc/draft-obispo-epp-idn/ Over 50% of those have your name on them, Scott. :) It's not clear to me looking at 3730 that there is a requirement to = register namespaces for use with EPP in the IANA. So maybe EPP isn't a = good yardstick after all. -andy= From shollenbeck@verisign.com Mon Jun 18 11:30:14 2012 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 DA4E021F8582 for ; Mon, 18 Jun 2012 11:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvcCy7kRGvvt for ; Mon, 18 Jun 2012 11:30:14 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7A78321F8559 for ; Mon, 18 Jun 2012 11:30:12 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT99zs3CjWemVVy1UPU0U9EQbakszX2xv@postini.com; Mon, 18 Jun 2012 11:30:13 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q5IIUBHJ021401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Jun 2012 14:30:11 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Mon, 18 Jun 2012 14:30:10 -0400 From: "Hollenbeck, Scott" To: Andy Newton Thread-Topic: [weirds] extensibility in weirds Thread-Index: AQHNTX710n8KD39u406QFjgknwXVKZcAZSqQ Date: Mon, 18 Jun 2012 18:30:10 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D61C8FA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20120618155442.GE32683@mail.yitter.info> <4FDF571A.3010703@mnt.se> <201206181739.q5IHdw2w013734@bartok.nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F0D61C880@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <1512BAB3-3855-45C5-9F53-C4A02AB669A3@hxr.us> In-Reply-To: <1512BAB3-3855-45C5-9F53-C4A02AB669A3@hxr.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 18:30:15 -0000 > -----Original Message----- > From: Andy Newton [mailto:andy@hxr.us] > Sent: Monday, June 18, 2012 2:20 PM > To: Hollenbeck, Scott > Cc: Jaap Akkerhuis; weirds@ietf.org > Subject: Re: [weirds] extensibility in weirds >=20 >=20 > On Jun 18, 2012, at 1:54 PM, Hollenbeck, Scott wrote: >=20 > >> AFAIK, there is hardly any extension documented in an RFC. > > > > Extension RFCs: > > > > http://datatracker.ietf.org/doc/rfc3915/ > > > > http://datatracker.ietf.org/doc/rfc4114/ > > > > http://datatracker.ietf.org/doc/rfc4310/ > > (obsolete by 5910) > > > > http://datatracker.ietf.org/doc/rfc5076/ > > > > http://datatracker.ietf.org/doc/rfc5910/ > > > > Extension I-Ds: > > > > http://datatracker.ietf.org/doc/draft-kong-epp-idn-variants-mapping/ > > > > http://datatracker.ietf.org/doc/draft-obispo-epp-idn/ >=20 > Over 50% of those have your name on them, Scott. :) True. It's probably more interesting to hear from extension writers who hav= en't documented their work in an IETF document. Scott From jaap@NLnetLabs.nl Mon Jun 18 11:42:58 2012 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 F329121F8656 for ; Mon, 18 Jun 2012 11:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd2AObFeCMFD for ; Mon, 18 Jun 2012 11:42:57 -0700 (PDT) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by ietfa.amsl.com (Postfix) with ESMTP id BE4B421F8657 for ; Mon, 18 Jun 2012 11:42:56 -0700 (PDT) Received: from NLnetLabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.5/8.14.5) with ESMTP id q5IIgqNC040580; Mon, 18 Jun 2012 20:42:52 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) X-DKIM: OpenDKIM Filter v2.5.2 bartok.nlnetlabs.nl q5IIgqNC040580 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=sleutel; t=1340044974; bh=4JKEoeCXkzRDIywRqtctva3EmfTq5sx66uTvv8bd4hM=; h=To:cc:Subject:In-reply-to:References:Date:From; b=NlMJh3NlKXEPz3AYffttHtWwARSdiqZ0ELi/s/S3jjw5xPEH7uF0AJEOl6WusKswJ mZ772I0B8l8zDPHoSG5OEqkTnxvlk3ugrD2Z1b4gm1b+zofieePt9sO0sR16+B+GYP RBvi2Kq7FN/S4T75cUD86jkvMshKQ5YiX0BLK7Xs= Message-Id: <201206181842.q5IIgqNC040580@bartok.nlnetlabs.nl> To: Andy Newton In-reply-to: <1512BAB3-3855-45C5-9F53-C4A02AB669A3@hxr.us> References: <20120618155442.GE32683@mail.yitter.info> <4FDF571A.3010703@mnt.se> <201206181739.q5IHdw2w013734@bartok.nlnetlabs.nl> <831693C2CDA2E849A7D7A712B24E257F0D61C880@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <1512BAB3-3855-45C5-9F53-C4A02AB669A3@hxr.us> Comments: In-reply-to Andy Newton message dated "Mon, 18 Jun 2012 14:19:48 -0400." Date: Mon, 18 Jun 2012 20:42:52 +0200 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (bartok.nlnetlabs.nl [127.0.0.1]); Mon, 18 Jun 2012 20:42:53 +0200 (CEST) Cc: "weirds@ietf.org" Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 18:42:58 -0000 >> AFAIK, there is hardly any extension documented in an RFC. > > Extension RFCs: Over 50% of those have your name on them, Scott. :) But there are way more extensions by various registries which are not published as an RFC. See for an example. I've once heard a story that some registries require an NDA to see documentation about their extensions. It's not clear to me looking at 3730 that there is a requirement to register namespaces for use with EPP in the IANA. I seem to remember that there isn't such a requirement. So maybe EPP isn't a good yardstick after all. I guess so. jaap From leifj@mnt.se Mon Jun 18 12:32:53 2012 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 66A4911E8089 for ; Mon, 18 Jun 2012 12:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.128 X-Spam-Level: X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=-0.529, 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 rXb+462yehJx for ; Mon, 18 Jun 2012 12:32:52 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id ACAAF11E80AD for ; Mon, 18 Jun 2012 12:32:51 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q5IJWlcI021382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Jun 2012 21:32:50 +0200 (CEST) Message-ID: <4FDF825E.9080805@mnt.se> Date: Mon, 18 Jun 2012 21:32:46 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: weirds@ietf.org References: <20120618155442.GE32683@mail.yitter.info> <4FDF519E.1000205@mnt.se> <20120618170506.GH32683@mail.yitter.info> In-Reply-To: <20120618170506.GH32683@mail.yitter.info> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 19:32:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2012 07:05 PM, Andrew Sullivan wrote: > On Mon, Jun 18, 2012 at 06:04:46PM +0200, Leif Johansson wrote: >> I'd go for expert review with a review policy that is explicitly >> permissive: your only goal is to keep nuisance-registrations >> out. > > I'm the co-ordinator of expert reviews for DNS RRTYPE numbers. > We've had a large number of process failures almost all of which > has resulted from experts just not completing things on time. Why > do we think this community would be more likely to have experts > with a lot of extra time to devote to this? A reasonable question. Would the RRTYPE numbers have been better served with a FCFS policy? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/fgl4ACgkQ8Jx8FtbMZncVZwCfXAGuuUdLOJEnc05L9RTzondu JyoAoIRox+6oiIN3A1JCdHa0geIYui4k =0O4v -----END PGP SIGNATURE----- From ajs@anvilwalrusden.com Mon Jun 18 12:54:06 2012 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 CCD5E21F8707 for ; Mon, 18 Jun 2012 12:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikQohWbDJfrF for ; Mon, 18 Jun 2012 12:54:06 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9FC21F8704 for ; Mon, 18 Jun 2012 12:54:06 -0700 (PDT) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 804911ECB41D for ; Mon, 18 Jun 2012 19:54:05 +0000 (UTC) Date: Mon, 18 Jun 2012 15:54:03 -0400 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20120618195403.GT32683@mail.yitter.info> References: <20120618155442.GE32683@mail.yitter.info> <4FDF519E.1000205@mnt.se> <20120618170506.GH32683@mail.yitter.info> <4FDF825E.9080805@mnt.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FDF825E.9080805@mnt.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 19:54:07 -0000 On Mon, Jun 18, 2012 at 09:32:46PM +0200, Leif Johansson wrote: > Would the RRTYPE numbers have been better served with a FCFS policy? No. RRTYPEs are dealing with an old protocol that originally couldn't cope with unknown RRTYPEs, the DNS has cacheing as a basic and fundamental part of how the protocol works, the RRTYPE number space is limited (though very large, and this isn't a major issue from my POV), and an RRTYPE can cause special server-side processing. So the expert is looking for those issues. I suppose it's logically possible that we could have special server-side processing (e.g. CNAME substitution), but I think redirects are more normal in http, no? Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From sm@resistor.net Mon Jun 18 14:04:14 2012 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 36EE911E80CA for ; Mon, 18 Jun 2012 14:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 LeDBeYM8d3pc for ; Mon, 18 Jun 2012 14:04:13 -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 6E77611E80CC for ; Mon, 18 Jun 2012 14:04:13 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5IL3xoG004499; Mon, 18 Jun 2012 14:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1340053444; i=@resistor.net; bh=debxRvX4h+nCfMawvn6Kl6gGFGYUDw+3KVR7EZ5ME10=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ZyWTaNO58+B2jgC4zArA2HUzioHGCA0bkVDhO7PfaWbRml9p88aoqYMHdsyFTpEcT OX89YO05DZM+LjPDQx5/raKOA7vvGeJ90H9c8a4eiao99UG59O+Rhzlk3+ST4A7bNp P5ICdghmVbEFIYSggWMq6ItZ+eamqZngyiZFXK0w= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1340053444; i=@resistor.net; bh=debxRvX4h+nCfMawvn6Kl6gGFGYUDw+3KVR7EZ5ME10=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=D3HwcNvsrYY/jnZFMMjrTy2g64ev9wwbStN88kWdNpi0PtcJMhPICxPv2ylqyzQ8u l4WkJjS3jcRsrnSKmTFoc6W36rwX1D8ReVuWu6fZfvlw/jQQsFqHxB51cW2SwbhjZI TEJtAVIc+jkUTilxt58z9/Sj9fj4zWdpnWuUWB1Q= Message-Id: <6.2.5.6.2.20120618133904.0a9174e0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 18 Jun 2012 13:48:10 -0700 To: Andy Newton From: SM In-Reply-To: References: <20120618155442.GE32683@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: weirds@ietf.org Subject: Re: [weirds] extensibility in weirds 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, 18 Jun 2012 21:04:14 -0000 Hi Andy, At 09:12 18-06-2012, Andy Newton wrote: >By FCFS, do you mean first come, first served? Do we have a real >concern that multiple registries are gonna rush to register the >"lunarNic" prefix? That should not be a concern unless people are going to use the registry for typosquatting. >I'm not exactly a huge fan of the registry idea, though I understand >the need. To me an independent submission of an informational does >not seem to be that big of a hill to climb, but I'm also somewhat >familiar with IETF process. Independent Submission is a big hill to climb for people unfamiliar with that hill. They'll probably want Individual Submission to get the rubber stamp of approval. It seems premature to get into a discussion about what kind of registration policy is more appropriate when there isn't any specification to discuss about. Regards, -sm From johnl@iecc.com Mon Jun 18 19:14:20 2012 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 B9D1311E80F0 for ; Mon, 18 Jun 2012 19:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.944 X-Spam-Level: X-Spam-Status: No, score=-110.944 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO1fMmox-eGf for ; Mon, 18 Jun 2012 19:14:19 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0F511E80D7 for ; Mon, 18 Jun 2012 19:14:19 -0700 (PDT) Received: (qmail 15280 invoked from network); 19 Jun 2012 02:14:18 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Jun 2012 02:14:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fdfe07a.xn--hew.k1206; i=johnl@user.iecc.com; bh=kKtasyG7Z/KSFrgVfHQayeSziDyrTw6L4aBCmUYusaE=; b=Q96STcL7sRW/63uWtE0xIl3UwcLh2o1bTw5nlz56wDaHzfHP4G2hoJWfw+zuxbiR+4WOOfqWhT5TJNj6a54ajA63B/rr7e/TWC2e4ngyzHuuKl5eXb7sxLhRuYuhgbSYI0fp7/tvfKZeBzoBOHnelxAi4D7OFdhg/QrK93PsGpg= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Jun 2012 02:13:56 -0000 Message-ID: <20120619021356.80103.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <20120618155442.GE32683@mail.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [weirds] extensibility in weirds 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, 19 Jun 2012 02:14:20 -0000 > what is wrong with FCFS? We are not the Internet Cops. "snhandle" Registrant's social network handle "fbhandle" Registrant's Facebook handle "rsocnet" Registrant's social network, e.g., Facebook, Google Plus "rhandle" Registrant's handle on social network "handleatsn" Registrant's handle in the form @, e.g., markz@facebook "hndlsndom" Registrant's handle in the form @domain, e.g., markz@facebook.com "manchesociale" Manche du registrant en reseau sociale "orkut" Punho registando no orkut Unlike RRTYPEs, ordinary clients are going to see all of the stuff that WEIRDS servers return, and it would be nice if we could parse it without a thousand special cases. Expert review works fine for MIME types. Perhaps the DNS crowd really is unusually dysfunctional. R's, John From zhoulinlin@cnnic.cn Mon Jun 25 18:48:24 2012 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 12E9A21F8582 for ; Mon, 25 Jun 2012 18:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_38=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 b3ltCAQIXGbi for ; Mon, 25 Jun 2012 18:48:23 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 1933D21F857F for ; Mon, 25 Jun 2012 18:48:21 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 26 Jun 2012 09:48:08 +0800 From: "Linlin Zhou" To: "'Leif Johansson'" References: <855AAE11-0D6A-4E60-91C4-1290AD1A99A4@arin.net> <4FDB441E.4000001@mnt.se> <4FDCFE89.7090409@mnt.se> <0438A104-86D2-4C73-B739-7085CFAC1D1D@mnt.se> <000301cd4d16$531d2290$f95767b0$@cn> <4FDEC615.70401@mnt.se> In-Reply-To: <4FDEC615.70401@mnt.se> Date: Tue, 26 Jun 2012 09:48:10 +0800 Message-ID: <002d01cd533d$be0dfa70$3a29ef50$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac1NGPBQ2mUF0AtfRzaNbCXWQs15jAGI3lzg Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] extensibility in weirds 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, 26 Jun 2012 01:48:24 -0000 > -----Original Message----- > From: Leif Johansson [mailto:leifj@mnt.se] > Sent: Monday, June 18, 2012 2:09 PM > To: Linlin Zhou > Cc: 'Alex Sergeyev'; weirds@ietf.org > Subject: extensibility in weirds > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > urn:somename is the namespace used in XML to avoid keys collisions. I > > think namespaces is templates that say what data is permitted and what > > value to give data that is not defined. JSON is a simple and light > > weighted protocol, so if a namespace is added, shall we have to first > > check whether all the objects included in the namespace? If so, I > > think it's a little complicated. > > > > I still don't get what anyone is saying on this topic. > > Structured names (like URIs) have *nothing* do do with XML per se. They are > neither more or less "complicated" than unstructured names and they do not > affect code in any reasonable way. > > I was making a point about extensibility. > Agreed. So in draft draft-kong-dnrd-ap-response-json-00, we prefer this way to show extension: { "domain": { ... }, "nameserver": [ ... ], "contact": [ ... ], "registrar": { ... }, "extension": { ... } } > Joe Levine seems to say that extensibility isn't necessarily in scope for weirds. > If so then the issues we discuss in this thread are of no consequence to weirds > and we can just stop this thread :-) > > If extensibility is needed and unless weirds wants to mandate that all > extensions must be based on published specs then some form of uniqueness for > JSON key names is needed. > > There are two ways to obtain uniqueness of identifiers: structured names or a > registry. Take your pick. > > However this may all be a moot point if extensibility isn't needed so perhaps > the WG should have consensus on that point first. > > > > >>> > >>> I also think that eventually it'll be strange when some keys have > >>> ":", and some do not. > >> > >> I don't get that either. > >> > > > > colon in JSON keys depending on coding style > > No it doesn't. These are not variables. JSON is not code but a data > representation language. > > Saying "colons are bad" is only true for variable names in certain languages but > no programming language that I've ever encountered has problems with colons > in strings. > I know that JSON can handle colon. I just feel a little uncommon to define a key like the namespace in XML. :) > Cheers Leif > Linlin Zhou From olaf@nlnetlabs.nl Fri Jun 29 01:36:59 2012 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 D1AE421F8713 for ; Fri, 29 Jun 2012 01:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 VU0DVrekyeKL for ; Fri, 29 Jun 2012 01:36:56 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C20821F86EE for ; Fri, 29 Jun 2012 01:36:52 -0700 (PDT) Received: from [172.16.18.216] (94.112.246.234.static.b2b.upcbusiness.cz [94.112.246.234]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.5/8.14.4) with ESMTP id q5T8amOK018311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Jun 2012 10:36:50 +0200 (CEST) (envelope-from olaf@nlnetlabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1340959010; bh=yfBsIVrLShWGZc3bj0Gi/ExkcHZZKP1aB/Lox53UHM8=; h=From:Subject:Date:To; b=V3Ri162Nc7itW+I/epzBeVkQMzDycT8oaTRNThUQYkE7C8JLHexoefnf+AaJOJBPZ goA4CRBxclhs0P7SgZHe4fBrzOeIniIawoYlfEP8p/Mu+eI5BybypBoJKMTu/RslIT zM3ti3z0DuLnVR/3WWY93uGRmcdK+zdi0WRhV1sA= From: Olaf Kolkman Content-Type: multipart/signed; boundary="Apple-Mail=_FFCF7DB7-A4C4-47EA-800B-3484CB1AD2CF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Fri, 29 Jun 2012 10:36:36 +0200 Message-Id: <55DAEBB6-6911-4F52-AB98-8F66FBA84F6E@nlnetlabs.nl> To: Web Extensible Internet Registration Data Service Working Group Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Fri, 29 Jun 2012 10:36:50 +0200 (CEST) Subject: [weirds] FYI: Weirds WG slot at IETF84 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, 29 Jun 2012 08:37:00 -0000 --Apple-Mail=_FFCF7DB7-A4C4-47EA-800B-3484CB1AD2CF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI, The weirds WG session is scheduled for: Wednesday, Morning Session I 0900-1130 Room Name: Regency F --Olaf --Apple-Mail=_FFCF7DB7-A4C4-47EA-800B-3484CB1AD2CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJP7WkUAAoJEFRqER47aqpkfaYP+gLeOEwfiBw94i6OnBhKA0ul bJPoQOJ2JI9YvO5iGdGeYdNr2ljdKi1UD/0+u1+SgT5QeJnpnsDWwhkE9B0fDnt9 RAEIMnin9lhmkvUomisj6wgV9hsPfyUiL6u0nnkiOl/TX4Cg4DwH40zO190MRLo0 FEaFcAseDOyYXbwmCj9Y5qoC6eoBQv8aEXaoXLAn8d0h2yEu/LINdZeUFcaMAhQ6 5ksLgFEVI3ZAXBhW3vTSDit5ep01mLQQMTF6r/j7q6XKIer0jnRPJF8E3twKeGGZ jY03SoumRf2d7KJwfQGrThqfhg+HxeAE3sgoJ+aRAd+OnG6NB0wQoPPbAAdEqcl/ UOeDLDzwwUnXynaCVcJeRzI/+9DysqNn5HzOk021KGhiwkZjZO9G7/UWEQlGHlAw UpOS11QDkZ+pwe6stRTqELlVg/7ZQDfK8Q1F05IS/q7AKZtNtOL3pD80uIte6wVs Z8fmW9jXIWAXrznWSLG5PYTC88ncy3i/DoJGaYxRPOA0Ekg7s2C5cN8P3sFwTs8/ KEzibH22DaMx/hBxNHmpJKqD3GwjOTi9J8JGKyHaD9U5A8hc5MJjHl4UOawuiUJI CfecXlNoE41aeBu6MXa9AN7Amj4ImDKMgkjDubTboQCiu9WQqZZ0hUj6YPdsDobr a5aiv9UDOc970pT8wRjR =UeE2 -----END PGP SIGNATURE----- --Apple-Mail=_FFCF7DB7-A4C4-47EA-800B-3484CB1AD2CF--