NCSG-DISCUSS Archives

NCSG-Discuss

NCSG-DISCUSS@LISTSERV.SYR.EDU

Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Ayden Férdeline <[log in to unmask]>
Reply To:
Ayden Férdeline <[log in to unmask]>
Date:
Wed, 15 Jun 2016 11:27:55 +0000
Content-Type:
multipart/alternative
Parts/Attachments:
text/plain (11 kB) , text/html (29 kB)
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

ATOM RSS1 RSS2