[gnso-rds-pdp-wg] IMPORTANT: Invitation for Poll from 9 May Meeting

Wed May 10 03:45:19 UTC 2017

I think I agree with Greg here on a couple of points.

I checked out the pdf version (thanks for making this version available, 
it is helpful) and I agree with the should/shall/must clarifications.  
Further, I would propose the following option:

Requestors *must* have access to thin data elements without either 
identifying or authenticating themselves.  It is recognized that some 
data elements currently forming part of the thin data set may be removed 
upon further deliberations on data elements.

[I recognize that anonymity is hard to find, but this makes explicit 
that if a requester makes an effort to obscure his/her/their identity, 
nothing can or should be done about it.  It also makes explicit that 
there is no need for authentication.  The second caveat is my usual 
one.....]

With respect to the next question, I really feel like we are parachuting 
into operational concerns, without necessarily dealing with the issues 
involved, at least for those of us to whom "rate limiting" is not an 
everyday activity or term we use.  It is not the case that there are no 
policy issues wrapped up in this, in my view.....once we establish that 
"anonymous" unauthenticated access is fine, is there a risk that there 
will be/is already wholesale vacuuming of data?  What is the downside of 
this? Would that be a violation of current RAA requirements, or rather 
would the lack of it indicate a violation?  are there anti-competitive 
actions at play in rate limiting? why was it (or more precisely, bulk 
access control) introduced into the RAA in the first place, and do those 
issues pertain today? these are questions that those of us not in the 
business might ask (at least I am asking, and I was one of very few 
non-commercial parties on the call today...I counted 2 but I may have 
missed somebody)

On a second unrelated note, I did the doodle polls for newcomer needs, 
hoping you might be offering a basic skills on managing WHOIS.  No luck 
there, but I commend that to you as a potential webinar....some of us 
(as may be clear by the questions above) would like to understand better 
exactly who looks for what data when and why, how that impacts the 
registrar/registry burden and the systems they run, volume and metrics 
and $$$.....
Stephanie Perrin

On 2017-05-09 22:28, Greg Aaron wrote:
>
> Dear Lisa and Chuck and everyone:
>
> I am wondering if this poll may be of limited utility because we may 
> be using the wrong words here, and the group may not share a crucial 
> common vocabulary.
>
> All four options ask about “authentication” but we have not defined 
> what that means.  Authentication is different from “anonymous” access, 
> and anonymous access is what we may actually be trying to discuss. 
> Note that the EWG recommended “anonymous” access for thin data.   The 
> distinctions are crucial.  Authenticated access is not really 
> anonymous, and the two terms tend to be mutually exclusive.
>
> So, can we please define those terms?
>
> Also, please note that the poll options use the term “should” -- but I 
> think the  word “must” was meant instead.   “Must” indicates something 
> mandatory, a requirement.   “Should” does not mean a thing is required 
> or mandatory – it is a recommendation or opinion that can be ignored.
>
> There is a standard reference we can use.  The terms MAY, MUST, MUST 
> NOT, REQUIRED, SHALL,  SHOULD and SHOULD NOT are defined in RFC 2119.  
> ( https://www.ietf.org/rfc/rfc2119.txt)   RFC 2119 defined those terms 
> for use in all subsequent RFCs.  The EWG was careful to use the above 
> terms according to RFC 2119 (see Final Report, page 18). ICANN 
> registry contracts, the TMCH RPM Requirements, and other ICANN efforts 
> have also used RFC 2119 as a definitional document.
>
> Clear definitions and choices of words really matter in policy-making, 
> and can help us all understand each other. I’m also noting this stuff 
> in email because the poll doesn’t have a notes or comments field.
>
> All best,
>
> --Greg
>
> **********************************
>
> Greg Aaron
>
> Vice-President, Product Management
>
> iThreat Cyber Group / Cybertoolbelt.com
>
> mobile: +1.215.858.2257
>
> **********************************
>
> The information contained in this message is privileged and 
> confidential and protected from disclosure. If the reader of this 
> message is not the intended recipient, or an employee or agent 
> responsible for delivering this message to the intended recipient, you 
> are hereby notified that any dissemination, distribution or copying of 
> this communication is strictly prohibited. If you have received this 
> communication in error, please notify us immediately by replying to 
> the message and deleting it from your computer.
>
> *From:* gnso-rds-pdp-wg-bounces at icann.org 
> [mailto:gnso-rds-pdp-wg-bounces at icann.org] *On Behalf Of *Lisa Phifer
> *Sent:* Tuesday, May 9, 2017 8:08 PM
> *To:* gnso-rds-pdp-wg at icann.org
> *Subject:* [gnso-rds-pdp-wg] IMPORTANT: Invitation for Poll from 9 May 
> Meeting
> *Importance:* High
>
> Dear all,
>
> In follow-up to today’s meeting, *all RDS PDP WG Members* are 
> encouraged to participate in the following poll:
>
> https://www.surveymonkey.com/r/BNKJ55R
>
> Responses should be submitted through the above URL. For offline 
> reference, a PDF of poll questions can also be found at:
>
> https://community.icann.org/download/attachments/64078610/Poll-from-9MayCall.pdf
>
> *This poll will close at COB Saturday 13 May.*
>
> Please note that you must be a WG Member to participate in polls. If 
> you are a WG Observer wishing to participate in polls, you must first 
> contact gnso-secs at icann.org <mailto:gnso-secs at icann.org> to upgrade to 
> WG Member.
>
> Regards,
>
> Lisa
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170509/460306ce/attachment-0001.html>