Subject: [weirds] Still a little disoriented

From: Edward Lewis <[email-masked]>
Date: Sun, 9 Sep 2012 19:25:15 -0400

I've been coming up to speed on the work in this WG.  (I was unable 
to make it to Vancouver.)

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 also appreciated the comments from Zhou Linlin 
(http://www.ietf.org/mail-archive/web/weirds/current/msg01497.html), 
"appreciated" in the sense that I haven't diven deep enough to say I 
agree or disagree.  But the sentiment in there rang a bell in me.

Registration breaks down into associating objects to entities. 
Whether it is domain name or IP numbers, there is that commonality. 
The more I think about it (having worked on both sides) there is much 
more in common than there is in difference.

E.g., IPv4 addresses are assigned or allocated in a hierarchical 
fashion.  The process to choose an appropriate range is an RIR topic, 
something not shared with a domain name registry.  RIRs are used to 
"linked" objects, e.g., 192.0.2.0/24 is one object that is kind of a 
parent to 192.0.2.192/26.  That relationship might appear to be 
unique to an RIR.  But domain name registries also have "links" 
between objects thanks to IDN variants.

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.

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.)

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.

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: Andy Newton <[email-masked]>
Date: Mon, 10 Sep 2012 14:31:57 +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.

>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Š]

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

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

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

>relationship labels to report.  I just want to call this out as a

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