Re: [weirds] Still a little disoriented

Andy Newton <andy@arin.net> Mon, 10 September 2012 14:32 UTC

Return-Path: <andy@arin.net>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4B21F86B8 for <weirds@ietfa.amsl.com>; Mon, 10 Sep 2012 07:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.152
X-Spam-Level:
X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_72=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH2sO6TVYyV7 for <weirds@ietfa.amsl.com>; Mon, 10 Sep 2012 07:32:12 -0700 (PDT)
Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id EEF5021F86AD for <weirds@ietf.org>; Mon, 10 Sep 2012 07:32:11 -0700 (PDT)
Received: by smtp2.arin.net (Postfix, from userid 323) id 6C619213666; Mon, 10 Sep 2012 10:32:11 -0400 (EDT)
Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id 942862135A6; Mon, 10 Sep 2012 10:32:10 -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; Mon, 10 Sep 2012 10:31:53 -0400
Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0298.004; Mon, 10 Sep 2012 10:31:58 -0400
From: Andy Newton <andy@arin.net>
To: Edward Lewis <Ed.Lewis@neustar.biz>, "weirds@ietf.org" <weirds@ietf.org>
Thread-Topic: [weirds] Still a little disoriented
Thread-Index: AQHNjuN/zPTpvz2BiEKy3N41lMtZ7peDpEiA
Date: Mon, 10 Sep 2012 14:31:57 +0000
Message-ID: <CC73697A.C5DF%andy@arin.net>
In-Reply-To: <a06240803cc72d04ebd97@[192.168.128.19]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.1.1.56]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <99E1629353D32C49A881984E6358371F@corp.arin.net>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [weirds] Still a little disoriented
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/weirds>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2012 14:32:13 -0000

Ed,

I'm not sure if you are seeking clarifications to issues or simply stating
overarching concerns, so in the interest of seeking rough consensus I'll
assume it is the former and respond in-line.

On 9/9/12 7:25 PM, "Edward Lewis" <Ed.Lewis@neustar.biz> wrote:

>I've read the three latest documents on
>http://tools.ietf.org/id/weirds?maxhits=100&key=date&dir=desc, and I
>say it as that because there is no other designation that these are
>associated with the WG (yet - I get the process, but I'm just saying).


I suggest you also read
http://datatracker.ietf.org/doc/draft-designteam-weirds-using-http/


>[ŠstrippedŠ]

>For that reason (and point example) I would strive to eliminate the
>mental divide between names and numbers in the documents.  This is in
>point 1 of Zhou's email.  There really ought not be any sense of
>division in the approach to the software.

I agree. In the unified drafts there really is one approach as one is a
complete subset of the other. The presentation was done to help show how
the needs of each community were being addressed. This helpful for showing
the overlap where there is overlap (keep in mind, that the RIR model has
objects that simply don't exist in the DNR model, specifically IP networks
and ASNs). However, I'm amenable to restructuring the draft into one model
if people feel that it makes the draft easier to understand.

>But not all is that shiny.  Beyond the basics of registration there
>are many policies unique to some registries.  Off hand I don't have a
>list, I just know there are rocks under the water.  There will be a
>need to make accommodations for this.  BUT but...as is a big debate
>in EPP, we don't want to make "extensions" that common.  (With a ;)
>to those who have ridden that issue for a few years now.)

Admittedly there are policy differences, but the problem domain is very
different from EPP. The EPP model is that client and server MUST agree on
the nature and detail of every object class, and derivation is done by
completely  replacing an object of one namespace with an object from
another. This is out of necessity because EPP is a read/write protocol
where money exchanges hands.

The approach defined in
http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-6.
2 takes a different approach. Extensions can be placed in-line; clients
that understand the extensions can make use of them and clients that do
not should ignore them. This is easier to do with a WEIRDS protocol as the
use is read-only.

>Point 2 in Zhou's message is also a concern of mine.  It's not just
>the timeliness.  The reason I subject'ed my message "Still a little
>disoriented" is that all of the documents I have seen seem to be more
>bent on presentation of the elements (queries and responses) than
>have any sense of data model or protocol architecture.
>
>When it comes to the "objects to entities" relationships managed by
>registries (and registrars where applicable), the various objects
>under consideration need to be defined.  This might help reduce the
>number of strings used to identify a particular kind of object.

Allow me to enumerate the object classes here:
1. Entity - organizations, people, groups, roles, etcŠ
2. Nameservers - sometimes called "hosts"
3. Domains - both forward and reverse
4. IP networks - both v4 and v6
5. ASNs - single and in block form

If it would help, we can put this summary in the introduction.

>
>E.g., a domain name might be owned by a organization.  In some RIRs
>an address range might be allocated to a organization.  In other RIRs
>the notion of a organization being in control of resource is not that
>direct.  To a querier wanting to know who to contact about a name or
>number resource, the "admin contact" is more or less what is needed -
>but that is called by different names.
>
>Each registry should be free to retain their own legal model and
>internal representation.  But a WEIRDS data model should allow that
>to be translated into a globally understood relationship label.
>
>And finally, I want to air once more the idea that registries have
>different policies placed on them and thus may have unique
>relationship labels to report.  I just want to call this out as a
>concern of mine.


I think we have done this with the entity object class. See Appendix A.2
(http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#ap
pendix-A.2) and Appendix B
(http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#ap
pendix-B)




-andy