Antoin, Good points. My feedback is embedded below.
— JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> On Aug 23, 2016, at 7:20 AM, Antoin Verschuren <i...@antoin.nl<mailto:i...@antoin.nl>> wrote: Op 22 aug. 2016, om 16:02 heeft Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> het volgende geschreven: Your response made me think a little bit more around the problem that is being solved. I see 2 problems that could be solved by formally defining the reseller and linking the reseller with objects in the registry: 1. Displaying the Reseller information in RDDS (RDAP). Right now it is the reseller name that needs to be displayed, but what if more information is needed later like E-mail, URL, Address, Contacts, etc.? 2. Enable registrars to set security, policy, and reporting options for reseller’s at the registry level. I can see many different use cases here that we’ve not yet fully discussed. Thoughts? Hi James, I fully agree with your use cases. Thank you for clarifying them. In addition this was actually my main question that has not been answered yet thinking ahead. Looking from a registration/registry perspective I think that a registrant/registrar/reseller/dns-operator is only a role an entity has for a specific registration. It is NOT a tag to the entity itself. You cannot say an entity IS a reseller, only that he performs a role as a reseller for a specific registration. It’s the relationship that is tagged, not the entity. You are correct that in reality, an entity could play multiple roles, but it’s the roles that are relevant from a system perspective to apply security, policy, functional, and reporting options. You could certainly have a conglomerate that serves multiple roles, but there are attributes that will be unique to each role. I don’t believe that the registry should not have multiple copies of information not applicable in the security, policy, functional, and reporting options defined in problem #2, but that may be unavoidable. I view the role taking priority over the entity in the domain registration data model, where there would be a role object that could reference a common entity, but it does not need to. Outside the registry relationship, an entity is appointed or "tagged” as a reseller by a registrar, but that contract is not what a registry administers. What happens if an entity is a registrant for one registration, a dns-operator for another one, a registrar for some others, and a reseller for yet another group? Will he be in the registry 4 times in 4 different tables, or only once? Let’s break down the data model based on who is authoritative for the information. Let’s say that “Jim” plays all of these roles for most likely a completely different set of objects: * “Jim” the Registrant - “Jim” the Registrant would register as a registrant with a registrar, who would be authoritative for the information. “Jim” the Registrant could register many domains that get registered in the associated registries (e.g. jim.example1 in EXAMPLE1 registry, jim.example2 in EXAMPLE2 registry). Do EXAMPLE1 and EXAMPLE2 registries really need “Jim” the Registrant information to fulfill their service? * “Jim” the DNS Operator - I believe we would need to discuss the domain registration data model, what functions are available in the registry, and who is authoritative for what information for “Jim” the DNS Operator. * “Jim” the Registrar - For ICANN accredited registrars, “Jim” the Registrar would be registered with ICANN, so ICANN would be authoritative for “Jim” the Registrar with the IANA ID as the globally unique identifier. The registry would need a reference to the registrar to map up to the registry credentials, finances, and to link to registry objects. For non-ICANN accredited registrars, then the Registry would be authoritative for “Jim” the Registrar unless there was some central non-ICANN accredited registrar authority. * “Jim” the Reseller - “Jim” the Reseller has a contract with a registrar, who would be authoritative for the information. “Jim” the Reseller’s registrar could create a link to “Jim” the Reseller in the registry that could be used to tag registry objects. The only information that is needed in the registry is the bare minimum to enable the linkage to solve problem #1 and #2. What if he is a reseller for multiple registrars? I would assume that he would be created as a separate entity for each registrar. The relationship is between the reseller and the registrar, where there is no need for a central repository that all of the registrars link to. What happens when he changes emailadress/phone number/address? He has to change the information in each place that is authoritative for the information. “Jim” the Registrant could register domains with multiple registrars, but there is no need for the registrars to reference a single instance of “Jim” the Registrant. Data is copied in this instance to multiple authoritative repositories, since there is no single authoritative repository for all entities and all entity roles. What happens when a reseller becomes a registrar for a new set of domains but remains reseller for the existing ones? Will his identifier and credentials change? No, they are viewed as different entities entirely. Yes, it may be exactly the same organization, but they are viewed as different entities from a system perspective. In my humble thought experiment, I think we should register a reseller the same as we do a registrar. The main difference between a registrar and a reseller is the contractual and business relationship. The registrars are setup in the registry with credentials, financial information, and access based on the contractual relationship. A reseller has no direct relationship with the registry, so although it is an organization, it has a completely different set of features from a registrar. It would be up to the registrar to register their resellers with the registry to be able to apply the appropriate security, policy, functional, and reporting options at the reseller level. As long as he does not have a registrar role for any registration, but only a reseller role, far less data is required, but the entity will need to get an identifier and credentials that do not change once he will get an additional role. I don’t believe that we would want or need to attempt to merge all of the roles into a single entity to support items like a reseller morphing into a registrar. The key is to keep the authoritative data with the authoritative source and link to those sources from non-authoritative parties. So it’s business logic to determine how much data is required and displayed depending on the role the entity has in a specific registration. But a phone number is a phone number, an emailaddress is an emailaddress, and there is no difference in definition in emailaddress requirements of a reseller compared to that of a registrant or any other entity that needs to be administered. Once the local registry policy determines the emailaddress field is mandatory for an entity in a reseller role, the definition of an emailaddress is still the same.. Can this be done, especially looking at the way registrar and registrant entities are treated different now? Should the registry be the one to provide this information? The registry may know of the relationships to support functionality, but having the registry get a copy of the data for display and making decisions as far as what to display runs into data privacy issues. The question of authoritative data versus informational is an interesting one. We need to know why the data needs to be in the registry in the first place. I believe that we should look at the data model for domain registration data and consider who is authoritative for each entity in the data model. Pushing data down to the registry simply to support displaying it in RDDS is not the correct architecture that scales and that meets the data privacy issues. In DNS we got away from the use of host files to use of a delegation resolution model. RDAP supports a delegation resolution model, so why not leverage it instead of pushing data around? If the data is to be used later for limited access rights to the database, like a dns-operator allowed to change an NS-set or a reseller allowed to change a registrant’s emailaddress, then it needs to be authoritative data from the registry perspective. Do we think that will never happen, or do we leave that decision to the business case of each individual registrar? I can imagine some registrars want to delegate some specific access rights and reporting, and others don’t. Should we provision for both, or only one use case? The question for DNS operators as it is for any other domain-based service operator (web, e-mail, DNSSEC, parking, secondary market, etc.) is whether they should be formally defined in the domain registration data model and if so who would be authoritative for the information, what role does the registry play, and what privileges would they have. Thoughts? - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
