Dear all,

 

Almost one week left before we must close the  collection process of any “possible” requirements to be added to the input list established and submitted by the GNSO PDP WG.

 

I would like to take this opportunity again to recall that the PDP WG is not expecting from us to work on this list and try to make any improvement. Instead, if any “possible” is found necessary to be added to this list before the final deliberation at the next ICANN meeting in Helisinki, it is welcome.

 

Therefore, I recommend that everybody reads again the charter questions and determine which “new” concern (from which source document) needs to  be addressed as a “possible “ requirement.

 

Counting on your usual collaboration.

 

Have a nice week.

 

--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__

Logo-new

 

 

De : Farell FOLLY [mailto:[log in to unmask]]
Envoyé : mercredi 15 juin 2016 10:06
À : 'Farell FOLLY'; [log in to unmask]
Objet : RE: Request for additional "possible" requirements for Next Generation RDS

 

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