[council] EPDP & Accreditation/Access Model

[Rubens Kuhl]

> Em 21 de set de 2018, à(s) 05:11:000, McGrady, Paul D. <PMcGrady at winston.com> escreveu:
> 
> Thanks Rafik.  Thanks Darcy.
> 
> Darcy, to respond to your request, I’m not sure that I can provide much more background on this than the letter itself, which is pretty self-explanatory.  We all know the history:
> 
> ·       GNSO Community working on various policy development efforts to address WHOIS, including protecting privacy and allowing disclosure for legitimate purposes.  .
> ·       GDPR comes into effect with deadline for fines.
> ·       Certain Contracted Parties become concerned about fines and work with Staff to develop the Temp Spec.  IPC and other folks who need disclosure for legitimate purposes practically beg Staff to include the details of a framework for such disclosures.
> ·       Staff produces a Temp Spec for the Board to implement which contains the requirement for disclosures but little detail.
> ·       Almost immediately, it is much more difficult to obtain needed disclosures for legitimate purposes, creating a safe haven for all sorts of Internet maladies.  We understand that some do not believe in the existence of this problem, but like most real things, the existence of the problem isn’t dependent on a need for 100% of people to believe in them.
> ·       Like Contracted Parties who saw an immediate problem and went to Staff seeking a Temp Spec while GNSO Community policy work was ongoing, IPC and others are working with Staff to (hopefully) get a Temp Spec in place addressing the details for a uniform/unified disclosure process while the Community work continues.  Hopefully, the EPDP produces Policy that finally, after decades of work, solves all of the above.
> 
> To the extent that the policy development process is being undermined by the letter it seems to me that it has already been undermined by the request by certain Contracted Parties for the Temp Spec.  That ship has sailed and, respectfully, certain of the Contracted Parties were at the helm.  I know this may be unpopular email, but I think it is best not to dance around the issues or try to get cute in explaining why the letter was sent.  I think as far as the EPDP is concerned, it seems like a non-issue, since as Rafik noted, the letter had no effect on the work of the EPDP.
> 


Paul,

Besides what has already been addressed by Michele that Contracted Parties long before Temp Spec asked (publicly as public forum records show) for guidance to be provided in due time (with no particular flavor of guidance being mentioned, like policy, contract amendment, temp spec etc.), what I need to communicate is that the use of a Temp Spec for the purposes it has already been used was already seen as an overstretch of something that was created for real emergencies (like the Conficker outbreak some years ago). A 2nd Temp Spec would likely face a barrage of responses including RfRs, IRPs and arbitration requests that make any such Temp Spec moot for longer than any PDP would take to complete.

That said, not doing a 2nd Temp Spec does not preclude a non-PDP solution. For instance, I still believe on a voluntary UAM developed by the larger registrars, LEAs and IP interests to have a greater chance of success than any policy effort could ever have. That model would also become a low-hanging fruit for a PDP because if there is something already in place encompassing 90% of domains, its adoption would turn out to be much easier.

This is not possible at this point due to the ongoing PDP discussions on Access, which are foundational in nature; but as soon as it concludes, I strongly recommend IPC and BC to reach out to the "Big Daddies / Large Cows" of the industry to build something that makes access requests scale. The unwilling uncooperative registrars, those that are 99.9% likely to not be RrSG members, are a different beast that ICANN's hammer is not big enough to pound; you can leave them to the men and women with badges and guns...



Rubens




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20180926/9f4f1ca5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/council/attachments/20180926/9f4f1ca5/signature-0001.asc>