Re: ROID how useful?
Francisco Obispo <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <[email protected]> |
On Dec 11, 2012, at 5:46 PM, "Gould, James" <[email protected]> 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 Director of Applications and Services - ISC email: [email protected] Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID = B38DB1BE _______________________________________________ provreg mailing list [email protected] https://www.ietf.org/mailman/listinfo/provreg