Patrick, Thank you for your thoughts to the possible use of the org drafts to help support transfers. You’ll find my feedback embedded below. — JG
James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/28/17, 12:46 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: Hello James, On Wed, Nov 22, 2017, at 20:11, Gould, James wrote: > As noted previously on the list, we have a propriatary Whois Info EPP > Extension > (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_whois-info_v01.html) > that provides the basics of the Registrar WHOIS Server, Registrar Name, > and the Registrar URL attributes. The org extensions can be extended to > provide additional registrar-level attributes in support of the transfer > policy. > > Thoughts? While I can see the train of thoughts (and while I completely sympathize with the idea that the current procedure to do transfers is illogical on an high scale even if all small parts are logical), I really do not think that the "org" extension would be a good fit to simplify current problems in transfer procedure, for various reasons: 1) it would mean adding some fields to each organization, that would make sense only for a registrar "role" organization, not for all organization objects; thus these fields would be very seldom populated, and it would make the schema not robust (it would be hard to define it in such a way that such elements are allowed if type=registrar but not with other types) I also remember that this extension was never defined at the beginning for registrars but for resellers You are correct that the extension was originally defined for resellers but was revised to be made generic to support any organization, including registrars. I believe the only fields missing include the reference to the RDDS services (WHOIS, RDAP). To keep the organization generic, this could be defined as a list of servers that may be set for an organization. This is not to be confused with the service “role”’s of the organization. A server could include a type (e.g., “whois”, “rdap”) and the connectivity information (e.g., URI, host / port). The idea here is to define an organization that can have one or more service roles and with zero or more typed server definitions. This way a registrar does not need to connect to a separate channel (e.g., WHOIS, RDAP) to option information that they can get directly via the secure EPP channel. 2) from what I recall, there was never a strong support from registrars for this reseller/org extension, as the goal and benefit/drawback comparison was not tilted in the good direction; if suddenly this extension becomes mandatory to conduct transfers, it means registrars would be forced to implement it even if it has a far broader scope than just enabling domain transfers The regext working group agreed to adopt the reseller extensions and to convert the reseller extensions to the more generic org extensions. I agree that the initial requirement of defining the reseller extension for the sole purpose of pushing data from the registrar to the registry to display in RDDS (Whois, RDAP) was not tilted in a good direction. This is an example of the RDDS Copy Authoritative Data Anti-Pattern. The use of the reseller extension for a broader set of purposes was discussed and subsequently the even broader org extensions were created. I’m not asking or proposing a requirement to implement the org extensions, but asking whether with the org extensions over the secure EPP protocol would be a better option than registrars getting information from the registries via an insecure channel that may become further restricted. If the registries do have the registrar information, then why can’t the registries provide the information over EPP to the registrars to support transfers? 3) as you state yourself, Verisign already has an extension tailored to that specific need for transfers, and I would far much prefer that this narrowly defined extension gets standardized and used for this specific need instead of trying to bolt the feature onto something that looks close to it but is definitely going after other goals. Why would you propose to create many small, targeted extensions to cover specific use cases instead of leveraging a more generic extension that is itself extensible (e.g., roles and servers) to support many use cases. Policies can and will change, where it’s best to define protocol extensions that best match the data model of the servers that can support a change in policies. I don’t view the org extensions has targeting other goals. One use case of the org extensions is to provide registrar information, so why not consider the registrar information needed in EPP to support transfers? I believe the only feature missing is the definition of typed servers, which is not a bolt on but an enhancement based on a concrete use case. Part of the current problems in the transfer procedure are in fact not technical but policy related (for example if you come to think about it, registrar R accredited in TLD X, Y and Z would probably have the exact same data as an organization in TLD X, Y and Z databases, or at least its whois server as I doubt registrar will define different whois servers they operate for each TLD they are in; so why is there a need to create this registrar structure in so many TLDs database where only one of them would be enough?). In such cases, no technical solution would make things better, so I believe the "org" extension not to be a good fit for that endeavour, and I advise not modifying it in that direction. I agree that the registrar information is best defined in a central registry as opposed to be replicated to each of the registries. If a centralized registrar registry was defined, then draft-ietf-regext-org-ext or draft-ietf-regext-org may need to be enhanced to support a delegation model. I’m thinking that it would be best to provide support for delegation of information in draft-ietf-regext-org, since the registry will have some additional registrar information beyond the address and contact information; although the registries will most likely cache the information anyway. If the registries due cache the registrar information, the org extensions can be used as is. I believe the point is that the registrars may need to know the sponsoring registrar information to support the transfer policy, and the org extensions provide the most secure and stable mechanism for this. -- Patrick Mevzek _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
