Patrick, My responses to your feedback are 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 1/7/18, 8:35 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Tue, Jan 2, 2018, at 15:11, Gould, James wrote: > 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 list of servers will have absolutely no meaning for organizations not being registrars. So the extension cease to be generic. I don’t believe registrars are the only organizations that may have a list of typed servers used for services. I would classify RDDS as a form of a service provided by a registrar. These servers are not limited to RDDS. Defining the RDDS servers is a concrete use case for a registrar organization that can be met by defining a generic mechanism that can apply to all organizations. > I’m not asking or proposing a requirement to implement the org > extensions, (I fear however that this could be a future outcome, if the use of the extension becomes mandatory to conduct transfers). I wouldn’t hinder the technical discussions based on a hypothetical future policy decision. > 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. I am not saying the contrary, but: - I think that the feature can be done otherwise/by other extensions - I do not want this extension to be suddenly perceived as absolutely mandatory because it is tied to the proper handling of transfers between registrars. I note that there was never a suggestion in the past if my memory works to introduce an extension to store registrars, so maybe the need to do that to better handle transfers was not obvious. There was for resellers, and then later it transformed into a generic organization handling. I’m not sure why you’re opposed to considering the use of the org extensions for the registries to provide registrar information that they already have over a secure channel in the support of transfers. We started with reseller that was pushed by the working group to be more generic to cover organizations like registrars, and now there is a concern about making it a requirement to solve a problem around transfers. > 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? They sure can. And maybe should. But we lived many years without that anyway. Yes, that is true, but access to RDDS may be changing, other extensions to provide Whois information (e.g., Verisign’s Whois Info Extension) have been created for transfers, and we can provide a more standard, secure, and extensible model to support transfers other than requiring registrars to access a separate non-secure registry channel with Whois. > 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. I'm inclined to the Unix philosophy of having many small tools that you can compose to produce what you need instead of a monolithic one trying to cover all cases and finally not being good in any case. I am not proposing to create other extensions because, as you already stated there is already one extension existing covering exactly the use case you are speaking about. As I said previously I would far more favor works towards making the existing extension a true standard used by multiple registries. Does Verisign plan to stop using its own extension and using instead the generic organization one we are talking about here if it includes the changes related to registrars whois/rdap servers? I don’t consider the organization extensions as monolithic in any way, but simply consolidating a potentially large set of small non-standard extensions into two extensions (org object extension and org command response extension) that provides an extensible framework. My hope is that we can come to agreement on a set of useful EPP extensions that can be standardized as opposed to encouraging a soup of proprietary extensions. The transition of proprietary extensions to standard extensions can be handled on a case-by-case basis. > I agree that the registrar information is best defined in a central > registry as opposed to be replicated to each of the registries. So I think this is the true issue to tackle but probably outside of this working group charter and also far more difficult, as not only purely technical level. I would theoritically prefer to see more energy spent on solving this issue at a generic level instead of hoping to solve it just with an EPP extension. The centralization of authoritative registrar data is architectural and is out-of-scope for this working group. The registries currently have the registrar data and will need to continue to have it for the foreseeable future. The org extensions can be leveraged based on the current architecture and can be used going forward for registrar data. > 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. So you are saying that the current EPP WhoisInfo extension designed to help registrars conduct transfers is not suited to do that? The Verisign Whois Info Extension does help registrars conduct transfers, but would need to be revised to support a reference to RDAP and potentially other information that is needed to support transfers in the future. Since org is an EPP object, it can be easily extended to support new and changing information via command / response extensions without having to extend the thousands or millions of provisioning objects (e.g., domains, hosts, contacts). All that is needed for the provisioning objects is to define the registrar role (draft-ietf-regext-org-ext) using an identifier that can be leveraged in a standard way to obtain the extensible registrar information. Just think about how many schemes (IANA ID, internal ID) are used for the clID element (domain:clID, host:clID, and contact:clID) and how the clID can’t be used to lookup any additional information. The orgext:id element in draft-ietf-regext-org-ext provides a typed identifier by an extensible set of roles that can be leveraged to lookup an extensible set of information defined in draft-ietf-regext-org. -- 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
