Subject: [provreg] ROID how useful?

From: Francisco Obispo <[email-masked]>
Date: Fri, 7 Dec 2012 18:30:31 -0800

The description of the ROID is very vague in the EPP docs. Besides keeping track of the history of a host object (because it's the only one which allows an identifier change), I don't see any uses for it.

The current EPP schema limits the roid to:

  <simpleType name="roidType">
        <restriction base="token">
          <pattern value="(\w|_){1,80}-\w{1,8}"/>
        </restriction>
  </simpleType>

Which does not allow me to use names like 'test.isc' as my ROID, (using .ISC imaginary TLD).

And one could think, we could use the -\w{1,8} (word that has a minimum of 1 to maximum of 8 chars) as the TLD (in case of domain objects), but that would not fit things like 'christmas' or 'blackfriday'.

We are currently generating a unique name using a hash function, but the results are very opaque: D_c12ed3266fd15ae54f4a10379c6bdd1b-ISC and besides generating a small overhead when creating the object, I don't find it very useful.

Our system supports multiple TLDs in the same registration system, so we intend to use something like:

C_<HASH>-<REGISTRY_ID> -> contact
D_<HASH>-<REGISTRY_ID> -> domain
H_<HASH>-<REGISTRY_ID> -> host

We will enforce global uniqueness but we really don't expect to use it anywhere.. 

EPP requests don't seem to reference anywhere except on the authInfo section of the Domain (RFC5731) doc in sec 3.1.3 when referring to the authInfo:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <command>
   C:    <transfer op="query">
   C:      <domain:transfer
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:        <domain:authInfo>
   C:          <domain:pw roid="JD1234-REP">2fooBAR</domain:pw>
   C:        </domain:authInfo>
   C:      </domain:transfer>
   C:    </transfer>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

And that's the only place where a contact is referred by the client by ROID and not by ID.

Since it is allowed to change the name of a host, I understand the need of having a special identifier for it, but is it really needed for everything else? 

Am I missing something important?

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

---

From: Francisco Obispo <[email-masked]>
Date: Fri, 7 Dec 2012 18:47:03 -0800

> Since it is allowed to change the name of a host, I understand the need of having a special identifier for it, but is it really needed for everything else? 

And even for this, the EPP command to update the host identifies it by its name and not by ROID, so keeping track of the name in the repository could be done in other ways.

If this is all true, why do we need a ROID ?

Francisco Obispo

---

From: Christopher Browne <[email-masked]>
Date: Fri, 7 Dec 2012 22:38:13 -0500

Any time the "natural" key is unique, there is little need for roids as
references.

In contrast, roids or some equivalent will prove necessary whenever the
natural key is NOT unique.

The scenario of that which leaps to mind is in respect to sunrise periods,
where there may be multiple applications for domains.  If there is need to
revise an application, during sunrise, for a domain, a roid would make a
decent unique reference.  Also, that offers a way to get WHOIS to return
data about a sunrise application.

The server trid of the application would also be a credible "unique"
candidate, though less natural for the WHOIS part.

---

From: Klaus Malorny <[email-masked]>
Date: Sat, 08 Dec 2012 15:11:02 +0100

On 08/12/12 03:30, Francisco Obispo wrote:
> The description of the ROID is very vague in the EPP docs. Besides keeping
> track of the history of a host object (because it's the only one which allows
> an identifier change), I don't see any uses for it.

Hi Francisco,

ROIDs can be used in conjunction with auth-infos. For example, with our registry 
software, the registrar can request the full contact data* of a non-sponsored 
contact object via <contact:info> if he specifies the ROID and auth-info of a 
non-sponsored domain object that references that contact object. This could be 
useful in preparation of a transfer, where the gaining registrar want to copy 
the original contacts.

RFC 5731 even allows to start a transfer with a referenced contact's auth-info 
and ROID, but this is too risky in our opinion, so we do not allow this.

Regards,

Klaus

* except its own auth-info

---

From: Francisco Obispo <[email-masked]>
Date: Sun, 9 Dec 2012 11:33:07 -0800

Hi Christopher,

On Dec 7, 2012, at 7:38 PM, Christopher Browne <[email-masked]> wrote:

> Any time the "natural" key is unique, there is little need for roids as references.
> 

+1

> In contrast, roids or some equivalent will prove necessary whenever the natural key is NOT unique.
> 

Exactly, but in case of domain names, contact ids, and host names, they all have natural keys.

> The scenario of that which leaps to mind is in respect to sunrise periods, where there may be multiple applications for domains.  If there is need to revise an application, during sunrise, for a domain, a roid would make a decent unique reference.  Also, that offers a way to get WHOIS to return data about a sunrise application.

I agree, in this case, we're not treating requests during the sunrise period as 'domains', we're just treating them as requests, which will go through or not to become registry objects 'after' a decision has been made by registry policy. So: yes, it is useful, but not necessarily part of the EPP protocol per se.

> 
> The server trid of the application would also be a credible "unique" candidate, though less natural for the WHOIS part.
> 

+1

Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Sun, 9 Dec 2012 11:37:41 -0800

Hi Klaus,
> 
> ROIDs can be used in conjunction with auth-infos. For example, with our registry software, the registrar can request the full contact data* of a non-sponsored contact object via <contact:info> if he specifies the ROID and auth-info of a non-sponsored domain object that references that contact object. This could be useful in preparation of a transfer, where the gaining registrar want to copy the original contacts.
> 

Yes, I understand that rationale, but why use the ROID there and not the contact-id as done everywhere else?

Also, if it's a  "Repository Object ID" what is the rationale behind that specific format? why are we forced to use: (\w|_){1,80}-\w{1,8}, when it should be a registry-defined attribute?

> RFC 5731 even allows to start a transfer with a referenced contact's auth-info and ROID, but this is too risky in our opinion, so we do not allow this.

I've heard similar comments from others with regards to that feature as well.

Francisco Obispo

---

From: Klaus Malorny <[email-masked]>
Date: Mon, 10 Dec 2012 12:35:03 +0100

On 09/12/12 20:33, Francisco Obispo wrote:
> [...]
> [...]

Hi,

all three are not unique over time. If you delete a domain and re-create it some 
time later, you have two different objects. A use of the ROIDs could have been 
to address registry objects in a generic way, but EPP does not make use thereof 
(except in the mentioned auth-infos). As such, it is indeed questionable why 
ROIDs are exposed in EPP.

Regards,

Klaus

---

From: "Gould, James" <[email-masked]>
Date: Mon, 10 Dec 2012 13:09:08 +0000

We used the ROID in the post-create commands for the Defensive
Registration and NameWatch object mappings in DotName since there could be
multiple registrations for the same string.  There are cases where the
registration name is not a unique identifier and there are cases where the
name can be changed like with hosts.  A history command for objects that
support changing name strings can show all of the transactions for the
object based on the ROID.  To note, the launch phase extension defines an
application identifier separate from the ROID, since the allocation of an
application to a domain might or might not result in a different ROID.

-- 

JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/10/12 6:35 AM, "Klaus Malorny" <[email-masked]> wrote:

>> Exactly, but in case of domain names, contact ids, and host names, they
>>all
>> have natural keys.
>> [...]
>
>Hi,
>
>_______________________________________________
>provreg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/provreg

---

From: Keith Gaughan <[email-masked]>
Date: Mon, 10 Dec 2012 13:23:20 +0000

> Exactly, but in case of domain names, contact ids, and host names, they all

Contact IDs, maybe, so long as it's up to the registry to generate them, but
domains and hosts? Not at all. If, say I register a domain and let it lapse, and
somebody else registers it, those can be considered independent objects with
separate identities, even though they refer to the very same domain.

The same goes for host objects and contact objects (if the registry doesn't
guarantee uniqueness).

K.

-- 
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 11 Dec 2012 14:57:02 -0800

Thank you all for your comments.

I'm wondering whether: (from rfc5731)

   When an <info> command has been processed successfully, the EPP
   <resData> element MUST contain a child <domain:infData> element that
   identifies the domain namespace.  Elements that are not OPTIONAL MUST
   be returned; OPTIONAL elements are returned based on client
   authorization and server policy.  The <domain:infData> element
   contains the following child elements:

contains an error, since I believe we should be referencing the contact by its ID in this case and not by its ROID.

>   C:    <clTRID>ABC-12345</clTRID>

It could mean that previous versions of the protocol did in fact use ROIDs as contact identifiers but it seems strange that this is the _only_ place where ROIDs are referenced as part of a query, everywhere else the contact:id is used.

How are others implementing it?

Francisco Obispo

---

From: "Gould, James" <[email-masked]>
Date: Tue, 11 Dec 2012 23:12:30 +0000

Francisco,

My feedback is below.

-- 

JG

James Gould
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 12/11/12 5:57 PM, "Francisco Obispo" <[email-masked]> wrote:

>contains an error, since I believe we should be referencing the contact
>by its ID in this case and not by its ROID.

What contains an error, the info response or the transfer query command?
The domain info response references the contact by ID and not by ROID.  If
you execute the contact info command of rfc5733, you can get the contact
ROID. 

>>   C:    <clTRID>ABC-12345</clTRID>

The authorization info provided in the transfer command can reference the
authorization info of the domain (without ROID) or the authorization info
of the domain's registrant (or contact object) by using the contact's ROID
and not the contact's ID.  The contact's ID could have been used but the
contact's ROID uniquely identifies the contact for this use case.

>
>
>It could mean that previous versions of the protocol did in fact use
>ROIDs as contact identifiers but it seems strange that this is the _only_
>place where ROIDs are referenced as part of a query, everywhere else the
>contact:id is used.

You are correct that this is the only place where the ROID is referenced
in the rfc commands; although they have been used with other EPP object
mapping commands as I posted previously to the list.

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 11 Dec 2012 15:23:11 -0800

Thanks James,

> you execute the contact info command of rfc5733, you can get the contact

For what I can see, any command querying the server that references the ROID, including: domain:info, domain:transfer, and contact:info

Unless it's querying an extension that specifically demands the ROID (history?)

> contact's ROID uniquely identifies the contact for this use case.

But the contact:id is unique as well right? 

From RFC5733:

  -  A <contact:id> element that contains the desired server-unique
      identifier for the contact to be created.

> mapping commands as I posted previously to the list.

Yes, and thanks for doing that, but those other commands that you mentioned are Verisign's extensions, and not part of the standard. I agree that there's use for a ROID, but not on the standard set of EPP query/transform commands (not responses).

Also, I don't understand why the format is enforced, when it should've been left open for the registry to decide.

Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 11 Dec 2012 15:45:03 -0800

contact:info doesn't include a "roid" option,

Only domain:[transfer/info]

info:
   -  An OPTIONAL <domain:authInfo> element that contains authorization
      information associated with the domain object or authorization
      information associated with the domain object's registrant or
      associated contacts.  An OPTIONAL "roid" attribute MUST be used to
      identify the registrant or contact object if and only if the given
      authInfo is associated with a registrant or contact object, and
      not the domain object itself.  If this element is not provided or
      if the authorization information is invalid, server policy
      determines if the command is rejected or if response information
      will be returned to the client.

transfer:
   -  A <domain:authInfo> element that contains authorization
      information associated with the domain object or authorization
      information associated with the domain object's registrant or
      associated contacts.  An OPTIONAL "roid" attribute MUST be used to
      identify the registrant or contact object if and only if the given
      authInfo is associated with a registrant or contact object, and
      not the domain object itself.

Francisco Obispo

---

From: "Gould, James" <[email-masked]>
Date: Wed, 12 Dec 2012 01:46:32 +0000

Francisco,

I'm really not sure what you are proposing.  The contact ID is unique within an individual registry while a roid is unique across all registries.  Referencing a contact roid with it's auth info that resides elsewhere is the only advantage that I can see over the use of the contact ID.  In both cases they are unique for supporting authorization of the domain info and transfer commands, so I don't believe there is a true issue with referencing the roid as the RFC is defined.  There are uses of roid for dealing with objects whose names can change like hosts and even custom object mappings like for DotName.

JG

James F. Gould
Principal Engineer
Verisign

[email-masked]

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 11 Dec 2012 18:04:53 -0800

On Dec 11, 2012, at 5:46 PM, "Gould, James" <[email-masked]> wrote:

> I'm really not sure what you are proposing.  The contact ID is unique within an individual registry while a roid is unique across all registries.
>  Referencing a contact roid with it's auth info that resides elsewhere is the only advantage that I can see over the use of the contact ID.  

I have not read any specifications on being able to use contact ids from other registries nor have a method for authenticating across multiple registries. If you guys have a use case that you can share, I'll appreciate it.

> In both cases they are unique for supporting authorization of the domain info and transfer commands, so I don't believe there is a true issue with referencing the roid as the RFC is defined.

Yes, but so is the contact:id, which is used to reference the contact everywhere else. I understand that if you want to refer to an object that existed in the past, you might want to use the ROID, but for something that exists in the database right now, the contact:id seems to be the natural fit.

>  There are uses of roid for dealing with objects whose names can change like hosts and even custom object mappings like for DotName.

I agree, but mostly to keep a differentiation of each instance of an object during its existence, i.e.: example.com was created, then deleted, then created by another registrar, the new registrar will only have access to the 'current' instance not the previous one. 

Having two ways to reference an object by a client: ROID + [name,id] seems confusing to me, ROIDs are useful for registrars and registries not so much for registrants.

Francisco Obispo

---

From: "Gould, James" <[email-masked]>
Date: Wed, 12 Dec 2012 02:48:50 +0000

Francisco,

My feedback is below.  

Are you proposing to change an RFC for this or just asking whether registries have implemented it?  We have implemented per the RFC.  I don't have any stats to share related to how often the roid has been referenced in the domain info or transfer commands.

JG

James F. Gould
Principal Engineer
Verisign

[email-masked]

> I have not read any specifications on being able to use contact ids from other registries nor have a method for authenticating across multiple registries. If you guys have a use case that you can s…

No we have not implemented such a use case but referencing a set of contact repositories is a possibility.

> Yes, but so is the contact:id, which is used to reference the contact everywhere else. I understand that if you want to refer to an object that existed in the past, you might want to use the ROID,…

Yes the contact ID could be referenced but that is not how the RFC is written and referencing via roid will work as well.

> Having two ways to reference an object by a client: ROID + [name,id] seems confusing to me, ROIDs are useful for registrars and registries not so much for registrants.

I'm not even sure if the contact ID is exposed to the registrant by the registrars but there are ways for the gaining registrar to get the roid of the registrant contact without the registrant having to enter it.  The auth-info of either the domain or registrant could be retrieved from the losing registrar and provided to the gaining registrar; although I believe it is unlikely whether we're talking about the use of roid or contact ID.  There are features of the RFC that could be lightly uses like the use of contact transfers.

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 12 Dec 2012 06:49:27 +0400

> I agree, but mostly to keep a differentiation of each instance of an object during its existence, i.e.: example.com was created, then deleted, then created by another registrar, the new registrar w…

Exactly, and for example:

If an object with the same object is deleted and then created again, the ROID change. If the object is just changing content (such as during a transfer) the ROID does not change.

For a registrar ROID is very important, specifically in some registry situations. It all depends though on how the registry is managing the objects during the lifetime of the object itself.

   Patrik

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 11 Dec 2012 18:53:01 -0800

I'm wondering whether it is there by an omission because of how the draft evolved into the RFC or a conscious decision by the authors.

If it is a conscious decision and everyone expects to use the roid and not the contact:id to perform transfers and privileged <info>'s, then I'm OK with it.

We also implemented as the RFC, but it feels 'wrong'.

Francisco

Francisco Obispo

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 11 Dec 2012 18:55:39 -0800

> If an object with the same object is deleted and then created again, the ROID change. If the object is just changing content (such as during a transfer) the ROID does not change.

Yes, however to request that transfer we use the [host,domain]:name or contact:id not the ROIDs, which is why it feels wrong to use the ROID for something less significant, like supplying the ROID of the contact in the authInfo.

> For a registrar ROID is very important, specifically in some registry situations. It all depends though on how the registry is managing the objects during the lifetime of the object itself.

Agreed, not so much for the registrant, who cares for his domain name.

Francisco Obispo

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 12 Dec 2012 07:04:00 +0400

> Agreed, not so much for the registrant, who cares for his domain name.

Agreed.

I.e. the registrar do have even in the case of a thick registrar a mirror of the registry database. To be able to keep these two in sync it is very very very important for a registrar to know:

- What operations can make the registry side change

- How is that detected

- How to do the sync so the two versions end up the same again

The ROID is very important for this.

For registrant, nope.

   Patrik

P.S. Hmm...I would like each registrar to describe those three things...that could be a useful exercise! :-)

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 12 Dec 2012 12:00:02 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Francisco Obispo
> Sent: Tuesday, December 11, 2012 9:53 PM
> To: Gould, James
> Cc: [email-masked]
> Subject: Re: [provreg] ROID how useful?
> 
> I'm wondering whether it is there by an omission because of how the
> draft evolved into the RFC or a conscious decision by the authors.
> 
> If it is a conscious decision and everyone expects to use the roid and
> not the contact:id to perform transfers and privileged <info>'s, then
> I'm OK with it.

The ROID concept wasn't part of the original EPP drafts that I wrote. It was added later at the suggestion of Patrik Fältström. The decision to use the ROID in the way documented in RFC 5731 was made consciously.

Scott