<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff">Alan,</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff">Thanks for your note.  I can't tell if you are responding or had seen the note I sent several hours ago.  In that note, I said differentiated access is essential and we must include it in our thinking.  I pointed out that trying to design access to public data under the assumption, either implicit or explicit, that differentiated access will not exist leads to a design that is poor in multiple ways.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff">One key point I did not cover in the memo is the distinction between differentiated access as a concept and SSAD as a particular proposal for achieving some aspects of differentiated access.  As we have heard, there are criticisms of the proposed design and significant open issues that have not yet been addressed.  Among the open issues, the most important is fleshing out the matrix of purposes, groups intended to have access for each purpose, the data elements they should receive, and performance requirements.  The overwhelming proportion of requests will have to be satisfied quickly and automatically.  Manual review is tolerable for only a small fraction of the total set of requests.  The best way forward, in my view, is to tackle the open issues.  That's apparently outside the scope  phase EPDP 2A, but I think it is very much within scope to be clear that this is a requirement.</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff">Thanks,</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff"><br></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff">Steve</div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small;color:#0000ff"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 21, 2021 at 11:02 PM Alan Greenberg via Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There continues to be discussion regarding using the SSAD as a means <br>
of "publishing" non-personal data.<br>
<br>
I believe that this discussion is a distraction that takes focus from <br>
what we should be working on. I say this for the following reason.<br>
<br>
1. The SSAD does not exist, it may never exist, and if the Board does <br>
approve it, it will likely take several years to implement (remember <br>
we are 2 years into the implementation of Phase 1, and there is no <br>
centralized hardware/software to design and implement for that).<br>
<br>
2. Although we specified that anyone may be accredited, it is not at <br>
all clear the amount of time it will take, nor what fee might be <br>
charged. And unless the system allows accreditation without <br>
authenticating the identity, this precludes anonymous queries.<br>
<br>
3. We specified that the SSAD must be self-funding and that the users <br>
must pay for its operating costs. Are those in favour of using the <br>
SSAD for public data publishing proposing fees for such requests, or <br>
no fees, and if the latter, who will pay for this usage?<br>
<br>
4. There are multiple details of Phase 2 Recommendation 8 for <br>
Contracted Party Authorization that simply make no sense in this <br>
case, yet are part of the approved policy. And changing that policy <br>
requires a PDP.<br>
<br>
5. There does not seem to be any benefit of routing public-data <br>
requests through the SSAD with its myriad rules, regulations and <br>
processes when a vanilla RDAP server will suffice.<br>
<br>
Alan<br>
<br>
_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" rel="noreferrer" target="_blank">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" rel="noreferrer" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.<br>
</blockquote></div>