Subject: Re: [regext] org extensions for transfer requirement

From: "Gould, James" <[email-masked]>
Date: Tue, 2 Jan 2018 14:11:56 +0000

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
[email-masked]

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" <[email-masked] on behalf of [email-masked]> 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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 08 Jan 2018 02:35:54 +0100

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’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).

> 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.

> 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.

> 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 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.

> 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?

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Mon, 8 Jan 2018 14:30:21 +0000

Patrick,

My responses to your feedback are embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 1/7/18, 8:35 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

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 wouldn’t hinder the technical discussions based on a hypothetical future policy decision.  

    

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.

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.   

    

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. 

    

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.  

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