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

Stephanie Perrin stephanie.perrin at mail.utoronto.ca
Wed May 10 15:19:27 UTC 2017


Yes you did make it clear Chuck, I am just including it as part of my 
footnote or derogation recommendation.  Feel free to gloss over it, this 
may get repetitive:-)

Stephanie


On 2017-05-10 10:07, Gomes, Chuck wrote:
>
> Thanks for the useful feedback Stephanie.  I trust that you will find 
> my response to Greg helpful.  I hope I made clear in yesterday’s call 
> what you say below, i.e., “It is recognized that some data elements 
> currently forming part of the thin data set may be removed upon 
> further deliberations on data elements.”
>
> Chuck
>
> *From:*gnso-rds-pdp-wg-bounces at icann.org 
> [mailto:gnso-rds-pdp-wg-bounces at icann.org] *On Behalf Of *Stephanie Perrin
> *Sent:* Tuesday, May 09, 2017 11:45 PM
> *To:* gnso-rds-pdp-wg at icann.org
> *Subject:* [EXTERNAL] Re: [gnso-rds-pdp-wg] IMPORTANT: Invitation for 
> Poll from 9 May Meeting
>
> 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>
>     [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 <mailto: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 <mailto: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/20170510/7563943e/attachment-0001.html>


More information about the gnso-rds-pdp-wg mailing list