Ayden,

I haven't gone through the (780) possible requirements - apologies.
Your mail sparked some thoughts that I mentioned earlier on-list, but
I'll bring up again.

----

One thing that I am curious about is whether there are requirements for
how access is delivered, as well as transparency and auditing of access
to data.

I am thinking of the case where a law-enforcement agency (LEA) gains
access to private data (like phone numbers). Ideally the LEA would have
to impose controls over who within the LEA has access to the data. For
example, it would be nice to know if a police officer was using RDS
data for extortion of stalking or the like - which can only be done if
the LEA has unique access credentials with strong authentication. I'm
not sure how this could be best made into a policy, but I think that it
is important (surely ICANN has experience with related
cross-organizational privacy restrictions from the registry/registrar
model).

Likewise, it would be good to know if an LEA (or anyone else) was
mining the data for mass-surveillance purposes or the like. While
registries may not be legally permitted to report such information,
there are good models that can be encouraged, such as:

https://en.wikipedia.org/wiki/Transparency_report

----

In a related topic, both registrars and registrants may want to know
when information about the registrant is accessed. (This is certainly
technologically possible. LinkedIn tells me how many people have looked
at my page when I log in.) As a registrant, I probably also want
context... if my basic data was shown 10 times in a month and my full
data was shown 2 times, is that less or more than average?

On the other hand, registrants may NOT want information stored about
access to their data, as any information that is stored can presumably
be accessed by LEA. That implies some sort of way for registrants and/or
registrars to specify preferences for the handling of meta-information
about who has accessed what records.

----

Again, sorry for not going through the possible requirements to see if
they are listed. I am being lazy and hoping that since you have put in
so much work on this that you will know roughly what is contained. ;)

Cheers,

--
Shane

At 2016-06-15 11:27:55 +0000
Ayden Férdeline <[log in to unmask]> wrote:

> One gap that I see among the (780) possible requirements is to do with under
> what conditions transfers of data to foreign jurisdictions is permitted.
> [CM-D30-R10] does talk about Privacy Shield and the transfer of data between the
> US and EU, but it doesn't seem sufficient to me. Does anyone know of any
> resources we can turn to re: restrictions on the overseas transfer of personally
> identifiable information? Would also be great if we had some case studies or
> costly judgements to include which make it clear that the data controller has
> legal liability for any breaches of privacy… I think we need to turn this debate
> into one about $$$ and less about privacy rights, because to come up with a
> wishlist of so many pieces of data to collect (and we are not yet even looking
> to consolidate this - just to expand it even further) seems not only unwise, but
> scandalously expensive. Particularly so if we go down the path of gated access
> and there are breaches - which there inevitably will be.
> - Ayden
> 
> 
> On Wed, Jun 15, 2016 10:06 AM, Farell FOLLY [log in to unmask] wrote:
> Dear all,
> 
> 
> 
> In addition to my previous e-mail, I think it would be nice to recall a brief
> history about the next-gen RDS. You can either read this e-mail for brevity or
> download the attached presentation (from which I withdrew the information).
> 
> 
> 
> 1. Why this PDP Working ?
> 
> 
> 
> WHOIS was created in the 80s to identify & contact those responsible for
> operation of Internet network resources. After nearly 15 years of GNSO task
> forces, working groups, workshops, surveys & studies, the ICANN community has
> been unable to reach consensus on comprehensive WHOIS policy reforms. In
> response to the 2012 WHOIS Policy Review Team’s Final Report, the ICANN Board
> launched the RDS PDP & the Expert Working Group (EWG) to inform it The EWG was
> tasked with taking a fresh approach by redefining the purpose of gTLD
> registration data & then proposing a new model for gTLD Registration Directory
> Services to address accuracy, privacy & access issues.
> 
> 
> 
> 2. What is WHOIS
> 
> 
> 
> <<WHOIS is an overloaded term, it could mean:
> 
> ü Registration data
> 
> ü Access protocol (WHOIS protocol)
> 
> ü Directory Service
> 
> ü It is best to use individual terms
> 
> 
> 
> It was created in 1982, but as the Internet grew, WHOIS began to serve the needs
> of different stakeholders such as registrants, law enforcement, intellectual
> property & trademark owners, businesses & individual users - but the protocol
> remained largely unchanged. Through the Affirmation of Commitments (AOC), ICANN
> is committed to “enforcing its existing policy relating to WHOIS, subject to
> applicable laws. Such existing policy requires that ICANN implement measures to
> maintain timely, unrestricted & public access to accurate & complete WHOIS
> information, including registrant, technical, billing, & administrative contact
> information.”>>  
> 
> 
> 
> 3. What is Next-Gen RDS
> 
> 
> 
> << In 2012, the ICANN Board resolved to
> 
> ü launch a new effort to redefine the purpose of collecting, maintaining, &
> providing access to gTLD registration data, & consider safeguards for protecting
> data, as a foundation for a new gTLD policy & contractual negotiations, as
> appropriate
> 
> ü Prepare an Issue Report on the purpose of collecting & maintaining gTLD
> registration data & on solutions to improve accuracy & access to gTLD
> registration data, as part of a Board-initiated GNSO PDP
> 
> ü These efforts are collectively known as the: Next-Generation gTLD Registration Directory Services to Replace WHOIS (Next-Gen
> RDS)>>  
> 
> 
> 
> This RDS is described by 180 principles and should address the following
> questions :
> 
> i. Users & Purposes
> 
> ii. Gated Access
> 
> iii. Privacy & Data Protection
> 
> iv. Data Quality
> 
> v. Data Elements
> 
> vi. Compliance & Accountability
> 
> vii. Implementation Model
> 
> viii. Cost
> 
> ix. Risks & Benefits
> 
> 
> 
> 
> 
> 
> 
> I hope this will help you understand more and stimulate your contribution.
> 
> 
> 
> 
> 
> --ff--
> 
> Best regards
> 
> ------------------------------------------------------------------------------
> 
> Farell FOLLY
> 
> Africa 2.0 Foundation
> 
> Chapter Head - Technology Champion
> 
> 
> 
> t: +22997 248100
> 
> s : Skype: farellf
> 
> m: [log in to unmask]
> 
> w :www.africa2point0.org
> 
> l : www.linkedin.com/in/farellf
> 
> tt : www.twitter.com/__f_f__
> 
> 
> 
> 
> 
> 
> 
> -----Message d'origine-----
> De : NCSG-Discuss [mailto:[log in to unmask]] De la part de Farell
> FOLLY
> Envoyé : lundi 13 juin 2016 17:13
> À : [log in to unmask]
> Objet : Re: Request for additional “possible” requirements for Next Generation
> RDS
> 
> 
> 
> (Sorry to have forwarded an unfinished e-mail, This is the final response)
> 
> 
> 
> @Shane, and all
> 
> 
> 
> The RDS PDP WG has the job to gather all “possible” requirements for the
> next-gen RDS to replace the WHOIS protocol. So many documents has been found
> useful / relevant to provide insightful issues to serve as inputs for the
> characteristics of the next-Gen RDS. However, WG found it impossible to read all
> documents together as a team and agree on what can be a “possible” requirement
> and what can/should not be a requirement (one by one, document per document).
> Then it was proposed and adopted that group members volunteer to read the docs
> and extract as many as inputs as possible. Then the ICANN staff worked hard and
> concatenated all these requirements by naming them appropriately without no
> change to the requirements themselves
> 
> 
> 
> Therefore the word “possible” means that the stated requirement may be removed
> at the end of the current phase if it is judged so. However, it is not yet time
> to make this decision.
> 
> 
> 
> Consequently, if you find any bogus or meaningless information (according to
> you), please just make a comment to me offline and I will forward to the staff
> as necessary. At this stage, we just need to propose new “possible”
> requirements, so if you think you have a new requirement for the next-gen RDS
> that is not already in the RDS PDP list I previously sent (or by discarding all
> inputs you classify as bogus or legalese), please send it/them through.
> 
> 
> 
> Finally for other members I would to clarify that each requirement has been
> given a specific annotation in the form of [QQ-R#-D#], for instance in
> [UP-D26-R06] : the first two letters identify the associated charter question
> (Users Purposes, in this case), the D26 identifies the input document (Annex A)
> from which the requirement has been extracted, and R06 means is the 6th
> “possible” requirement).
> 
> 
> 
> I suggest to anyone in this group to read (in priority, iteratively) a sub-list
> of all these “possible” requirements depending or based on his/her expertise or
> background. For instance, If you have experience in data privacy, you can
> quickly check all “possible” requirements starting by [PR-Dxx-Ryy] and a new one
> if any. For any new “possible” requirement, don’t forget to add the source
> document.
> 
> 
> 
> --ff--
> 
> Best regards
> 
> ------------------------------------------------------------------------------
> 
> Farell FOLLY
> 
> Africa 2.0 Foundation
> 
> Chapter Head - Technology Champion
> 
> 
> 
> t: +22997 248100
> 
> s : Skype: farellf
> 
> m: [log in to unmask]
> 
> w :www.africa2point0.org
> 
> l : www.linkedin.com/in/farellf
> 
> tt : www.twitter.com/__f_f__
> 
> 
> 
> 
> 
> 
> 
> -----Message d'origine-----
> 
> De : Shane Kerr [ mailto:[log in to unmask] ]
> 
> Envoyé : lundi 13 juin 2016 15:37
> 
> À : Farell FOLLY
> 
> Cc : [log in to unmask]
> 
> Objet : Re: Request for additional “possible” requirements for Next Generation
> RDS
> 
> 
> 
> Farell,
> 
> 
> 
> At 2016-06-13 11:30:10 +0100
> 
> Farell FOLLY < [log in to unmask] > wrote:
> 
> 
> 
> > Few months ago I decided to join the NCSG in order to serve and defend  
> 
> > the interest of the community regarding Internet resources use. Before  
> 
> > that, I started working with the GNSO Policy Development Process  
> 
> > Working Group (PDP  
> 
> > WG) to contribute in the development process of the Next Generation  
> 
> > Registration Directory Services (Next-Gen RDS). Time comes now that I  
> 
> > engage more and participate within this stakeholder Group. Therefore,  
> 
> > I volunteer to serve as a liaison/point of contact between NCSG and  
> 
> > GNSO PDP WG as far as the attached documents are concerned.  
> 
> 
> 
> Cool, thanks for this!
> 
> 
> 
> > 1. Read the outreach message 2 in attach  
> 
> >  
> 
> > 2. Read and check the RDS PDP list of possible requirements, also in  
> 
> > attach  
> 
> >  
> 
> > 3. Reply to this mail by asking any questions to me or adding  
> 
> > additional requirement  
> 
> >  
> 
> > Please before replying to this e-mail to add a “new” requirement, make  
> 
> > sure you read the entire document and check whether this requirement  
> 
> > was not duplicated already. Also, ensure that you send your contact  
> 
> > details (name, first name, e-mail) if not explicitly included in your mail  
> signature.
> 
> 
> 
> [ Apologies if the following reads as a rant. It kind of is. Probably
> 
> my own fault for looking at policy stuff. ]
> 
> 
> 
> Is there a summary of the PDF, or any kind of specific issues that seem
> contentious that one would look at?
> 
> 
> 
> I ask because the PDF alone is over 100 pages. Is this a typical ICANN document?
> I was going to have a look since I'm somewhat technical and was involved with
> WHOIS in the distant past, but honestly I don't really have the many days time
> that would be necessary to make any sense out of this. :(
> 
> 
> 
> ------
> 
> 
> 
> I did skim a bit, and while parts of it are pretty clear:
> 
> 
> 
> [UP-D01-R17] – Since it is likely that further [permissible
> 
> purposes] will be identified over time, any [gTLD registration
> 
> directory service] must be designed with extensibility in mind.
> 
> 
> 
> (This is a bogus requirement, BTW. Without specific descriptions of the expected
> changes then it is impossible to implement. It's like someone saying “prepare
> for the weather tomorrow” without telling you what the weather will be. Better
> to leave this out and let people make their own design decisions.)
> 
> 
> 
> Other parts are complete legalese:
> 
> 
> 
> [UP-D26-R06] – According to the Directive (30), whereas, in order
> 
> to be lawful, the processing of personal data must in addition be
> 
> carried out with the consent of the data subject or be necessary
> 
> for the conclusion or performance of a contract binding on the data
> 
> subject, or as a legal requirement, or for the performance of a
> 
> task carried out in the public interest or in the exercise of
> 
> official authority, or in the legitimate interests of a natural or
> 
> legal person, provided that the interests or the rights and
> 
> freedoms of the data subject are not overriding....subject to the
> 
> provisions allowing a data subject to object to the processing of
> 
> data regarding him, at no cost and without having to state his
> 
> reasons;
> 
> 
> 
> I mean, really, the last person to use “whereas” in English outside of legal
> documents died before the invention of the telephone. ;) (The Wikipedia article
> on plain English suggests “because” or “since”, as does the “ www.plainlanguage.gov ” site, although in this particular case I'd say just leave it out.)
> 
> 
> 
> I don't even know what the requirement is here. I read it 4 times and can't
> figure it out. I feel sorry for the poor software engineer that has to try to
> convert this to running code. :P
> 
> 
> 
> Given the many hundreds of possible requirements, many of which are written like
> this, I don't see any way that anyone who has anything else to do for before the
> deadline can possibly hope to help properly review this work, at least without
> some coordinated plan such as “please review the following 10 requirements” for
> 50 volunteers.
> 
> 
> 
> Sorry for ranting. :(
> 
> 
> 
> Cheers,
> 
> 
> 
> --
> 
> Shane
> 
> 
> Ayden Férdeline Statement of Interest