Re: [regext] org extensions for transfer requirement

[Gould, James]

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  

On 1/7/18, 8:35 PM, "regext on behalf of Patrick Mevzek" 
 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 

Re: [regext] org extensions for transfer requirement

[Gould, James]

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  

On 12/28/17, 12:46 AM, "regext on behalf of Patrick Mevzek" 
 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 

Re: [regext] org extensions for transfer requirement

[Patrick Mevzek]

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

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

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.

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.


-- 
  Patrick Mevzek

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] org extensions for transfer requirement

[Linlin Zhou]

Dear James,
Thanks for your detailed explanation. I agree that the org extensions could 
help to get more organization-level information, such as registrar. The 
registry have organization information from registrar which could be posted in 
WHOIS., and on the other side, the registrar could also get org information 
from registry to help the authentication process. What about others thoughts?



Linlin Zhou
 
From: Gould, James
Date: 2017-11-23 03:11
To: Linlin Zhou; regext
Subject: Re: [regext] org extensions for transfer requirement
Linlin,
 
What was discussed was leveraging the organization drafts to provide registrar 
information in support of transfers.  The EPP auth info value that is validated 
by the Registry is currently a single authentication factor in performing a 
transfer, while the second authentication factor performed by the Registrar is 
the Form of Authorization (FOA), 
https://www.icann.org/resources/pages/foa-auth-2004-07-12-en, which is directly 
dependent on WHOIS (Registry and Registrar) information.  As outlined in the 
ICANN Transfer Policy, 
https://www.icann.org/resources/pages/transfer-policy-2015-09-24-en, the 
Gaining Registrar must receive authorization from the Registered Name Holder 
(registrant) or the Administration Contact (admin) as listed in the losing 
registrar’s or applicable registry’s WHOIS service with the FOA. The Losing 
Registrar must also send an FOA to the Registrant.  The following pieces of 
information is needed to retrieve what is needed to populate the FOA for the 
Gaining Registrar and the Losing Registrar:
 
1.  Gaining Registrar
a.   Registrar WHOIS server from Registry WHOIS
b.  Registrant and admin contact email addresses from Thick Registry WHOIS 
or Registrar WHOIS
c.   Registrant and admin name from Thick Registry WHOIS or Registrar WHOIS
d.  Losing Registrar Name from Registry WHOIS
e.   May need the Losing Registrar Web URL for coordination.
2.  Losing Registrar (Registrar of Record)
a.   Registrant and admin contact email addresses from Losing Registrar 
system
b.  Registrant and admin name from Losing Registrar system
c.   Gaining Registrar Name by mapping transfer query response 
 element to name 
  i.  There is 
no standard mechanism known for definition of  (e.g., use of 
Registry Account ID, use of IANA ID)
ii.  There is 
no standard mechanism for looking up the Registrar Name given the  
value.  WHOIS provides registrar lookup by name and not by ID. 
d.  May need the Gaining Registrar Web URL for coordination.
 
Considering that the Registry has the Registrar information, why is the Gaining 
Registrar and Losing Registrar going to WHOIS to obtain the information needed 
to authenticate a transfer?  There are problems with this that the org 
extensions may help:
 
1.  Having to access a separate protocol to obtain information that is 
available in the Registry.  Specifically, the information that can be made 
available via the org extensions in EPP using a standard lookup key (e.g., 
organization identifier ) include:
a.   Registrar WHOIS Server
b.  Registrar Name
c.   Registrar URL and other attributes to help with coordination
2.  Access to the registrant and admin contact name and email addresses.  
How is this information made available today and will that change in the future 
(WHOIS, RDAP, differential access)?  
a.   More may be needed of the trusted channel with the Registry and the 
org extensions to coordinate the transfer policy.
 
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?  
 
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com 
 
From: regext <regext-boun...@ietf.org> on behalf of Linlin Zhou 
<zhoulin...@cnnic.cn>
Date: Monday, November 20, 2017 at 8:13 PM
To: regext <regext@ietf.org>
Subject: [EXTERNAL] [regext] org extensions for transfer requirement
 
Dear all,
Sorry that I can't attend the Singapore meeting in person, but I've followed 
the discussion remotely. I heard that org extensions could be used for transfer 
requirement in addtion to providing some generic organization information to 
the registry. Could James or Roger give us some more details on this? I think 
we need some discussions to optimize the org extensions and push them forward. 
 
Regards,


Linlin Zhou
___
regext mailing list
regext@ietf.org
https://ww

Re: [regext] org extensions for transfer requirement

[Gould, James]

Linlin,

What was discussed was leveraging the organization drafts to provide registrar 
information in support of transfers.  The EPP auth info value that is validated 
by the Registry is currently a single authentication factor in performing a 
transfer, while the second authentication factor performed by the Registrar is 
the Form of Authorization (FOA), 
https://www.icann.org/resources/pages/foa-auth-2004-07-12-en, which is directly 
dependent on WHOIS (Registry and Registrar) information.  As outlined in the 
ICANN Transfer Policy, 
https://www.icann.org/resources/pages/transfer-policy-2015-09-24-en, the 
Gaining Registrar must receive authorization from the Registered Name Holder 
(registrant) or the Administration Contact (admin) as listed in the losing 
registrar’s or applicable registry’s WHOIS service with the FOA. The Losing 
Registrar must also send an FOA to the Registrant.  The following pieces of 
information is needed to retrieve what is needed to populate the FOA for the 
Gaining Registrar and the Losing Registrar:


1.  Gaining Registrar

a.   Registrar WHOIS server from Registry WHOIS

b.  Registrant and admin contact email addresses from Thick Registry WHOIS 
or Registrar WHOIS

c.   Registrant and admin name from Thick Registry WHOIS or Registrar WHOIS

d.  Losing Registrar Name from Registry WHOIS

e.   May need the Losing Registrar Web URL for coordination.

2.  Losing Registrar (Registrar of Record)

a.   Registrant and admin contact email addresses from Losing Registrar 
system

b.  Registrant and admin name from Losing Registrar system

c.   Gaining Registrar Name by mapping transfer query response 
 element to name

  i.  There is 
no standard mechanism known for definition of  (e.g., use of 
Registry Account ID, use of IANA ID)

ii.  There is 
no standard mechanism for looking up the Registrar Name given the  
value.  WHOIS provides registrar lookup by name and not by ID.

d.  May need the Gaining Registrar Web URL for coordination.

Considering that the Registry has the Registrar information, why is the Gaining 
Registrar and Losing Registrar going to WHOIS to obtain the information needed 
to authenticate a transfer?  There are problems with this that the org 
extensions may help:


1.  Having to access a separate protocol to obtain information that is 
available in the Registry.  Specifically, the information that can be made 
available via the org extensions in EPP using a standard lookup key (e.g., 
organization identifier ) include:

a.   Registrar WHOIS Server

b.  Registrar Name

c.   Registrar URL and other attributes to help with coordination

2.  Access to the registrant and admin contact name and email addresses.  
How is this information made available today and will that change in the future 
(WHOIS, RDAP, differential access)?

a.   More may be needed of the trusted channel with the Registry and the 
org extensions to coordinate the transfer policy.

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?

—

JG

[cid:image001.png@01D3639B.D79938A0]

James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com

From: regext  on behalf of Linlin Zhou 

Date: Monday, November 20, 2017 at 8:13 PM
To: regext 
Subject: [EXTERNAL] [regext] org extensions for transfer requirement

Dear all,
Sorry that I can't attend the Singapore meeting in person, but I've followed 
the discussion remotely. I heard that org extensions could be used for transfer 
requirement in addtion to providing some generic organization information to 
the registry. Could James or Roger give us some more details on this? I think 
we need some discussions to optimize the org extensions and push them forward.

Regards,

Linlin Zhou
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext