Subject: [weirds] observations so far....

From: Francisco Obispo <[email-masked]>
Date: Tue, 12 Mar 2013 01:33:44 -0700

I'm currently working on our implementation of RDAP.

So far I've found three things that I think should be improved:

1) When describing a DNR Domain Object Class, the "phones", structure
   as shown here:

    "phones" :
         {
           "office" : [ "1-958-555-4321", "1-958-555-4322" ],
           "fax" :    [ "1-958-555-4323" ],
           "mobile" : [ "1-958-555-4324" ]
         },

  assume that we have information whether the phone is of an 'office' or 
  'mobile', which does not match the EPP schema where we only collect:
  voice, and fax (with ext).

  perhaps the easiest way to solve this issue is by adding a 'voice' 
  key.

2) the field entityNames is an array reference with strings signifying
   the names of the entity.

   In a domain registry, via EPP we collect name and org, we can probably
   fit the two in there, but it leaves no pointers on which is which.

   I wold like to maintain the definition of what is a name and what is 
   an org, this is specially useful when formatting for humans, even though
   some don't care about that.

3) It is confusing how each object type lays out the information within
   the format. I personally don't like object attributes at the same level
   as the protocol spec, makes the resulting output more difficult to read.

   In addition, the concept of: 'roles' in an 'entity' is redundant, and
   generates additional processing, because entities associated with an
   object are not longer just 'rendered' they need to be checked to see
   where in the 'parent' object is referenced in order to set the field.

   Fortunately it is not present in the example of DNR Domain Object, 
   and even though I added it to mine, it seems unnecessary.

As soon as I have a beta, I'll share the link with the list.

Francisco Obispo 
Director of Applications and Services - ISC
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 12 Mar 2013 17:32:15 +0800

>    and even though I added it to mine, it seems unnecessary.
That's what I'm going to point out. 
The RIR entity has the object of 'roles' while the DNR entity doesn't. 

> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =
> B38DB1BE
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 Mar 2013 06:26:04 -0400

>    perhaps the easiest way to solve this issue is by adding a 'voice'

This will hopefully be solved by vCard. :)

See here:
http://tools.ietf.org/html/rfc6350#section-6.4.1

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Andy Newton <[email-masked]>
Date: Tue, 12 Mar 2013 13:29:23 +0000

>The RIR entity has the object of 'roles' while the DNR entity doesn't.

The both have it. The draft splits out RIR and DNR for the understanding
of what might be expected from those types of services, but the attributes
are allowed in both objects.

>From Section 1 Paragraph 2 of json-response:

The data model for the responses consists of two major categories:
   responses returned by Regional Internet Registries (RIRs) for
   registrations data related to IP addresses, reverse DNS names, and
   Autonomous System numbers; and responses returned by Domain Name
   Registries (DNRs) for registration data related to forward DNS names.
   The RIR object classes are a proper subset of the DNR object classes.
   The current division between RIR and DNR object classes is given to
   illustrate an expectation of what data may be expected from an RIR vs
   a DNR.  However, implementers should be aware that RIRs are not
   limited to the data in the RIR object classes (as an example, some
   RIRs have a notion of "status" for entities as defined in the DNR
   entity object class and may at some point start publishing that
   data).

That text may need be clarified, but we've wrangled it before.

-andy

---

From: James Mitchell <[email-masked]>
Date: Wed, 13 Mar 2013 00:51:34 +1100

The roles model does suit the DNR object, its just a different way of
looking at the data presented over EPP. It supports roles outside the core
EPP spec, for example reseller or the operations and notifications (OPN)
contact used in the .asia sunrise, however one could argue for such
information to be expressed as their own attributes/names.

I do however have issues with the example presented in the draft, comments
below.

1. the entity in the DNR Domain Object example response should include its
role(s). I cannot tell whether the entity is a registrant, admin, billing,
tech, or registrar, or all of the above. If we remain with the 'roles
model' I would expect that the role attribute would be "mandatory" in
response to a domain query, otherwise it is potentially meaningless?

2. The use of the sponsoredBy attribute is inconsistent with the use of
domain contacts; apparently both registrar and domain contacts are
entities however both are treated completely differently in the response.
I would expect registrars and domain contacts are either attributes of
domain objects (with full information either available inline or through
links) or the sponsoring registrar included in the entities section (both
illustrated below). I'm sitting on the fence for this one, perhaps leaning
towards an entities section. Regardless any method that allows me to
return only names and links would suffice.

Example with attributes:
{
name:"abc.example",
Š
sponsoredBy:{handle:"SponsorXYZ",
link:"http://example.net/registrar/SponsorXYZ", ... },
registrant:{handle:"XXXX", link:"http://example.net/contact/XXXX"
<http://example.net/contact/XXXX%22>},
-- or --
registrant:{handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe
Shopping" ], Š},
Š
}

Example with entities:
{
name:"abc.example",
Š
entities:
[
{handle:"SponsorXYZ", name:"Registrar 123", role:"registrar", Š},
{handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopping" ],
role:"registrant", Š}
]
Š
}

Regards,
James

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 12 Mar 2013 22:04:25 +0800

It's a little confused presented by the two JSON response examples. 
Clear now. Thanks.

> -----Original Message-----
> From: Andy Newton [mailto:[email-masked]]
> Sent: Tuesday, March 12, 2013 9:29 PM
> To: Linlin Zhou; 'Francisco Obispo'; [email-masked]
> Subject: Re: [weirds] observations so far....
> 
of
> what might be expected from those types of services, but the attributes
are
> allowed in both objects.

---

From: Andy Newton <[email-masked]>
Date: Tue, 12 Mar 2013 14:30:55 +0000

>It's a little confused presented by the two JSON response examples.

Linlin,

I'm sympathetic to this issue and will think about how we can make it
clearer.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 12 Mar 2013 16:34:19 +0000

James,

>return only names and links would suffice.
..[snipped]..
>{handle:"XXXX", entityNames: [ "Joe Bob, Inc.", "Bobby Joe Shopping" ],

Yes, this is an inconsistency. And it doesn't just exist with sponsoredBy
but also with lastChangedBy, registrationBy, and resoldBy.  This
convention comes out of the RIR way of doing things where the only
information regarding these is either a NIC handle or email address.

I think converting this into roles and modeling them as entities is more
consistent with the rest of the model as long as we are willing to accept
that the entities may be very sparse. As in:

{ "handle" : "ALN-ARIN", "roles" : "lastChangedBy" }
Or 
{ "emails" : [ "[email-masked]" ], "roles" : [ "lastChangedBy" ] }

That last example will get more exciting when we transition to jCard.
Either that or we accept the fact that in some registries the handle might
be an email address (which I'm fine with as well).

-andy

---

From: Francisco Obispo <[email-masked]>
Date: Sun, 17 Mar 2013 21:11:25 -0700

Hi Linlin,

would it be possible to also structure the postalAddress from:

"postalAddress" :
         [
           "123 Maple Ave",
           "Suite 90001",
           "Vancouver",
           "BC",
           "12393"
         ],

to something like:

"postalAddress":{
	"street":["123 Mapple Ave","Suite 90001"],
	"city":"Vancouver",
	"sp":"BC",
	"pc":"12393"
	"cc":"CA"
}

Since EPP carries all of these elements, it should be very straightforward for a names registry to provide the information as described here.

We don't want to lose information, (in this case metadata), unless we strictly have to.

Thanks

Francisco Obispo

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 18 Mar 2013 18:21:47 +0800

Hi Francisco,

I think this issue has been raised in the list, see
http://www.ietf.org/mail-archive/web/weirds/current/msg02005.html. I prefer
the structured response rather than the flat format myself.
Another question do we reach the common consensus to reuse vcard? If so,
which format the rdap server is going to support, structured, flat or both?

Regards,
Linlin

> From: Francisco Obispo [mailto:[email-masked]]
> Sent: Monday, March 18, 2013 12:11 PM
> To: Linlin Zhou
> Cc: [email-masked]
> Since EPP carries all of these elements, it should be very straightforward
for a
> names registry to provide the information as described here.
> 
> We don't want to lose information, (in this case metadata), unless we
strictly
> have to.
> >> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE
> >>
> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE

---

From: Arturo Servin <[email-masked]>
Date: Mon, 18 Mar 2013 08:11:37 -0300

I would say both.

	There are some databases where the data today is flat, so it would be
impossible to do structured. I would expect some effort from those
registries in the future to convert (by some automatic or manual
process, or asking users to update their information) the data from flat
to structured, but for today that would be very difficult and a barrier
to implement rdap.

	Abandoning structured would give us perhaps a not very complete protocol.

	So, as today I would prefer a mean to do any of those depending of the
needs of the registry.

/as

---

From: "John Levine" <[email-masked]>
Date: 18 Mar 2013 16:25:44 -0000

>would it be possible to also structure the postalAddress from:

Didn't we address this in December?

http://www.ietf.org/mail-archive/web/weirds/current/msg01994.html

R's,
John

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 18 Mar 2013 11:22:23 -0700

Thanks for sharing the link.

I'm glad I came to the same conclusion as Gavin,

One thing we could do, instead of dealing with 'flat' or 'structured' subfields, we could rely on the data type, that is, if it has a hash, we assume it's a structure, and if it has an array, then it's flat.

Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 18 Mar 2013 11:29:41 -0700

I remember migrating whois data (back in 2004) from rwhois (flat files) to a registry system with structured data.

Since the data was actually 'there' but in a 'flat' format, we had to write a whole bunch of code to detect the various fields. We were actually able to detect the data successfully in about 80% of the records, the other 15 or so , required a bit of tweaking or even some writing of custom code, the other 5 was all done by hand :-(.

However, if a registry still has this data in a flat form, I'm envisioning that they will have trouble dealing with other fields as well, so even though I want to be realistic about making this protocol a success, we should also encourage those registries to update their systems, and normalize the data.

Francisco Obispo

---

From: MICHAEL YOUNG <[email-masked]>
Date: Mon, 18 Mar 2013 14:39:51 -0400

Hi Francisco,

This makes a lot of sense to me, I know it may slow the adoption, but in terms of net numbers, the vast bulk of the current registry data is structured already, so I don't think it causes that much harm to adoption to push for normalized data. 

-Michael Young

> Phone: +1 650 423 1374 || INOC-DBA *3557* NOC

MICHAEL YOUNG
[email-masked]

---

From: Arturo Servin <[email-masked]>
Date: Mon, 18 Mar 2013 15:49:26 -0300

Eventually, but not now.

	I am in favor on supporting both approaches as:

	For only structured, I would object.

/as

---

From: Francisco Obispo <[email-masked]>
Date: Mon, 18 Mar 2013 12:02:54 -0700

Setting a 'structured' subfield in something that has a structure, seems redundant/inappropriate to me.

how about using the type detection?

hash  -> structured
array -> flat 

?

Francisco Obispo

---

From: Arturo Servin <[email-masked]>
Date: Mon, 18 Mar 2013 16:04:20 -0300

No problem with this.

.as

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Mon, 18 Mar 2013 16:18:36 -0300

'Like'

---

From: Simon Perreault <[email-masked]>
Date: Tue, 19 Mar 2013 10:22:48 +0100

Did you people all suddenly forget about vCard?

This is exactly the kind of stuff that WEIRDS should not bother with. 
Let's instead reuse what is already in the IETF's toolkit.

Simon