Re: [regext] DOODLE: select your documents

2019-01-25 Thread Tobias Sattler
Hi everyone,

After seeing the result of the vote, I, as a representative of a domain 
registrar, must express my serious concern about the RDAP Reverse Search 
document.

A reverse search enables third parties to query RDAP, among other things, so 
that all associated domains can be queried using an email address. I consider 
this to be very questionable for data protection reasons.

In addition, such queries can lead to a very high load and strongly influence 
other systems - depending on the implementation of the service.

Furthermore, as far as I know, there is currently no requirement for such 
functionality - neither from ICANN nor from other registries / registrars. 
Which is why I want to suggest that this document should not be adopted for now.

Best regards,
Tobias

> On 18. Jan 2019, at 17:00, James Galvin  wrote:
> 
> The DOODLE was officially closed Friday.  There was additional person who 
> selected documents bringing the total number of contributors to 21.  The 
> additional selections did not material change the ranking of the choices.
> 
> Based on raw numbers, the following 5 documents are preferred:
> 
> 14 Federated Authentication for RDAP
> 9 RDAP Partial Response
> 8 RDAP Reverse Search
> 8 RDAP Sorting and Paging
> 8 Login Security
> 
> For completeness, I will also observe that if you take out the “maybe” votes, 
> the ranking does not change.
> 
> The chairs are making the following assumption at this point: if you selected 
> a document then you will work on the document.  This assumption should be 
> addressed when you vote to adopt a document, where we will ask you to make it 
> explicit.
> 
> The next thing that is needed is to formally adopt these documents and to set 
> milestones for them.  In addition, recall that we agreed with our area 
> director to have only 5 milestones open at a time.  Here is the process we 
> will use to achieve these two goals.
> 
> 1. The chairs will send out a call for adoption for each of the documents.  
> Folks MUST respond and either agree or disagree with the adoption of each 
> document.  Instructions will be in each message.
> 
> 2. There are two milestones on our list that do not match these 5 documents.  
> The chairs will send out a call for objections to removing those two 
> milestones from our list.
> 
> 3. After we have adopted our documents we will start a discussion of setting 
> the milestones for the adopted documents.
> 
> Thanks to those who participated in the Doodle poll.
> 
> Antoin and Jim
> 
> 
> 
> 
> On 21 Dec 2018, at 11:13, James Galvin wrote:
> 
>> Please take the time to select the documents you support for advancement in 
>> this working group.
>> 
>> https://doodle.com/poll/6nyguby3yr8dx9cp
>> 
>> Please select from 1-5 documents.
>> 
>> If you click once in the box a green check mark will appear.  Use this to 
>> indicate support for a document.  If you click twice in the box a yellow 
>> check mark in parentheses will appear.  You may use the yellow check mark to 
>> indicate support that is a lower priority than a green check mark.
>> 
>> For your convenience I have included the list of documents and their links 
>> below.
>> 
>> This selection process will remain open for 3 weeks, until 11 January 2019.
>> 
>> Enjoy your holiday season!  See you all next year!
>> 
>> Jim
>> 
>> 
>> DOCUMENTS TO CONSIDER
>> 
>> Registry Reporting Repository
>> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-reporting-repo/
>> 
>> Registry Reporting Structure
>> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-registry-report-structure/
>> 
>> Domain Fee Report
>> https://datatracker.ietf.org/doc/draft-sattler-registry-domain-fee-report/
>> 
>> Registry Transaction Report
>> https://datatracker.ietf.org/doc/draft-mcpherson-sattler-ry-transaction-report/
>> 
>> Registry Domain Inventory Report
>> https://datatracker.ietf.org/doc/draft-sattler-registry-domain-inventory-report/
>> 
>> Registry Domain Drop Report
>> https://datatracker.ietf.org/doc/draft-sattler-registry-domain-drop-report
>> 
>> Registry Unavailable Domain Report
>> https://datatracker.ietf.org/doc/draft-sattler-registry-unavailable-domain-report/
>> 
>> Registry Maintenance Notifications
>> https://datatracker.ietf.org/doc/draft-sattler-epp-registry-maintenance/
>> 
>> Unhandled Namespaces
>> https://tools.ietf.org/html/draft-gould-casanova-regext-unhandled-namespaces
>> 
>> Data Set File Format
>> https://datatracker.ietf.org/doc/draft-gould-regext-dataset/
>> 
>> Login Security
>> https://datatracker.ietf.org/doc/draft-gould-regext-login-security/
>> 
>> Federated Authentication for RDAP
>> https://datatracker.ietf.org/doc/draft-hollenbeck-regext-rdap-openid/
>> 
>> RDAP Partial Response
>> https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-partial-response/
>> 
>> RDAP Search
>> https://datatracker.ietf.org/doc/draft-fregly-regext-rdap-search-regex/
>> 
>> RDAP Reverse Search
>> https://datatracker.ietf.org/doc/draft-loffredo

Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Niels ten Oever
Hi Thomas,

On 1/25/19 4:18 PM, Thomas Corte wrote:
> Hello Niels,
> 
> On 1/25/19 15:39, Niels ten Oever wrote:
> 
>> But if the IETF produces protocols which are non-GDPR compliant upon 
>> implementation, and are violating human rights, that is imho not something 
>> we should want. 
> 
> Why should the IETF, a *global* organization, restrict its protocols to
> ensure GDPR compliance, i.e. a piece of legislation only applicable in
> the *European Union* and nowhere else?
> 

I fully agree that the IETF does not need to restrict its protocols to the 
legislations of one geographical area. But I think the IETF should help 
implementers to not violate the human rights of end-users, and consider 
regulation when implementing. The IETF can seek to do so by thoroughly 
analyzing the potential impacts of the protocols that are produced in and 
published by the IETF and report on the in privacy, security and human rights 
considerations. 

Best,

Niels

PS The legislation not only applicable in the European Union, but anywhere in 
the world where the data of EU citizens or residents is held.


> Best regards,
> 
> Thomas
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Mario Loffredo


Il 25/01/2019 15:39, Niels ten Oever ha scritto:


On 1/25/19 3:28 PM, John R Levine wrote:

The final decision on this is planned to be made in April:

https://community.icann.org/pages/viewpage.action?pageId=88574682&preview=/88574682/102142026/EPDP_summary_timeline_20190116.pdf

Not that it's relevant here, but I am a member of the ICANN SSAC subcommittee 
that supports the SSAC reps on the EPDP group, and I talk to them about its 
progress or lack thereof several times a week.  I think it's fair to assume 
that I know at least as much about what it's doing as anyone else here.

I do not doubt anything of this. Would you agree that the decision of the EPDP 
impacts how RDAP reverse search should be developed and implemented?


No because I don't believe that someone is thinking to an uncontrolled 
implementation and, even if someone is so crazy to do that, he will be 
responsible for that, not the capability. RDAP was born to overcome the 
WHOIS limitations. The policies described in RFC7481 allow RDAP servers 
to provide capabilities according the user profiles and there are a 
number of operators legitimated (in terms of GDPR lawful bases) to use 
RDAP reverse search.





I was also a member of the IAOC when we figured out what the IETF needed to do 
to be GDPR compliant (not much.)


Because the IETF does not implement the protocols or holds the data. But if the 
IETF produces protocols which are non-GDPR compliant upon implementation, and 
are violating human rights, that is imho not something we should want.


According to that view, WHOIS should have been stopped even before the 
entry into force of GDPR and, after that time, also fully GDPR compliant 
WHOIS implementations should have been switched off because other 
non-GDPR compliant implementations were still running.



Can we distinguish between the technology and the use/misuse of the 
technology ? If we don't make this distinction, why don't we shutdown 
Internet ??



Anyway, a new version of the draft will be available soon. Hopefully, 
this new version will fix the controversial points.



Regards,

mario


Best,

Niels


But once again, the IETF is not ICANN, working groups are not GDPR data 
controllers, nor are we GDPR data processors.  This entire argument is a waste 
of everyone's time.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Thomas Corte
Hello Niels,

On 1/25/19 15:39, Niels ten Oever wrote:

> But if the IETF produces protocols which are non-GDPR compliant upon 
> implementation, and are violating human rights, that is imho not something we 
> should want. 

Why should the IETF, a *global* organization, restrict its protocols to
ensure GDPR compliance, i.e. a piece of legislation only applicable in
the *European Union* and nowhere else?

Best regards,

Thomas

-- 

 |   |
 | knipp |Knipp  Medien und Kommunikation GmbH
  ---Technologiepark
 Martin-Schmeißer-Weg 9
 44227 Dortmund
 Deutschland

 Dipl.-Informatiker  Tel:+49 231 9703-0
 Thomas CorteFax:+49 231 9703-200
 Stellvertretender LeiterSIP:thomas.co...@knipp.de
 Software-EntwicklungE-Mail: thomas.co...@knipp.de

 Registereintrag:
 Amtsgericht Dortmund, HRB 13728

 Geschäftsführer:
 Dietmar Knipp, Elmar Knipp

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Mario Loffredo

Hi Andy,

Il 25/01/2019 16:02, Andy Newton ha scritto:

On Fri, Jan 25, 2019 at 10:12:19AM +0530, Gurshabad Grover wrote:

On 23/01/19 6:25 PM, Niels ten Oever wrote:

[...]
In this draft, there are no privacy considerations, and the report that is 
being cited to legitimize this approach has not been adopted by ICANN the 
organization or the community and was very controversial at the time of 
publication. The report is being miscited as being produced by ICANN itself, 
which was not the case.
[...]

I agree with Niels:

* Since the document starts with outlining privacy concerns as being of
primary import and relevance to the discussion around reverse search,
the document would naturally benefit from adding privacy considerations.

* The reference to a ICANN WG's recommendations as "... ICANN itself, in
its report about Next-Gen Registration Directory Service (RDS) ..." is
also problematic.

Thank you.
Gurshabad

If the authors removed this introductory text, would you drop your objections?


I'm removing that text from the new version as well as I'm adding a 
"Privacy Consideration" section.


Regards,

mario


-andy

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: mario.loffr...@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Andy Newton
On Fri, Jan 25, 2019 at 10:12:19AM +0530, Gurshabad Grover wrote:
> On 23/01/19 6:25 PM, Niels ten Oever wrote:
> > [...]
> > In this draft, there are no privacy considerations, and the report that is 
> > being cited to legitimize this approach has not been adopted by ICANN the 
> > organization or the community and was very controversial at the time of 
> > publication. The report is being miscited as being produced by ICANN 
> > itself, which was not the case. 
> > [...]
> 
> I agree with Niels:
> 
> * Since the document starts with outlining privacy concerns as being of
> primary import and relevance to the discussion around reverse search,
> the document would naturally benefit from adding privacy considerations.
> 
> * The reference to a ICANN WG's recommendations as "... ICANN itself, in
> its report about Next-Gen Registration Directory Service (RDS) ..." is
> also problematic.
> 
> Thank you.
> Gurshabad

If the authors removed this introductory text, would you drop your objections?

-andy

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Niels ten Oever


On 1/25/19 3:28 PM, John R Levine wrote:
>> The final decision on this is planned to be made in April:
>>
>> https://community.icann.org/pages/viewpage.action?pageId=88574682&preview=/88574682/102142026/EPDP_summary_timeline_20190116.pdf
> 
> Not that it's relevant here, but I am a member of the ICANN SSAC subcommittee 
> that supports the SSAC reps on the EPDP group, and I talk to them about its 
> progress or lack thereof several times a week.  I think it's fair to assume 
> that I know at least as much about what it's doing as anyone else here.  

I do not doubt anything of this. Would you agree that the decision of the EPDP 
impacts how RDAP reverse search should be developed and implemented?

> I was also a member of the IAOC when we figured out what the IETF needed to 
> do to be GDPR compliant (not much.)
> 

Because the IETF does not implement the protocols or holds the data. But if the 
IETF produces protocols which are non-GDPR compliant upon implementation, and 
are violating human rights, that is imho not something we should want. 

Best,

Niels

> But once again, the IETF is not ICANN, working groups are not GDPR data 
> controllers, nor are we GDPR data processors.  This entire argument is a 
> waste of everyone's time.
> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread John R Levine

The final decision on this is planned to be made in April:

https://community.icann.org/pages/viewpage.action?pageId=88574682&preview=/88574682/102142026/EPDP_summary_timeline_20190116.pdf


Not that it's relevant here, but I am a member of the ICANN SSAC 
subcommittee that supports the SSAC reps on the EPDP group, and I talk to 
them about its progress or lack thereof several times a week.  I think 
it's fair to assume that I know at least as much about what it's doing as 
anyone else here.  I was also a member of the IAOC when we figured out 
what the IETF needed to do to be GDPR compliant (not much.)


But once again, the IETF is not ICANN, working groups are not GDPR data 
controllers, nor are we GDPR data processors.  This entire argument is a 
waste of everyone's time.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Niels ten Oever



On 1/25/19 3:14 PM, John R Levine wrote:
>> If a registrant is living in the EU, or a EU citizen, they would be covered 
>> by GDPR protections, so its impact is quite significant. As you know, ICANN 
>> and the industry is seeking to find one compliance model. I do not see why 
>> we would deviate from that.
> 
> I pretty sure nothing has changed since Wednesday, so I guess we're done.

The final decision on this is planned to be made in April:

https://community.icann.org/pages/viewpage.action?pageId=88574682&preview=/88574682/102142026/EPDP_summary_timeline_20190116.pdf

> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread John R Levine

If a registrant is living in the EU, or a EU citizen, they would be covered by 
GDPR protections, so its impact is quite significant. As you know, ICANN and 
the industry is seeking to find one compliance model. I do not see why we would 
deviate from that.


I pretty sure nothing has changed since Wednesday, so I guess we're 
done.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Tom Harrison
On Fri, Jan 18, 2019 at 05:04:20PM +0100, Antoin Verschuren wrote:
> ...

I support adoption and am willing to contribute/review.

-Tom

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-hollenbeck-regext-rdap-openid

2019-01-25 Thread Tom Harrison
On Fri, Jan 18, 2019 at 05:03:29PM +0100, Antoin Verschuren wrote:
> ...

I support adoption and am willing to contribute/review.

-Tom

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-partial-response

2019-01-25 Thread Tom Harrison
On Fri, Jan 18, 2019 at 05:03:45PM +0100, Antoin Verschuren wrote:
> ...

I support adoption and am willing to contribute/review.

-Tom

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-sorting-and-paging

2019-01-25 Thread Tom Harrison
On Fri, Jan 18, 2019 at 05:04:11PM +0100, Antoin Verschuren wrote:
> ...

I support adoption and am willing to contribute/review.

-Tom

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


Re: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

2019-01-25 Thread Niels ten Oever



On 1/24/19 7:15 PM, John Levine wrote:
> In article  you 
> write:
>> I totally agree with John here: let's await what comes out of the ICANN EPDP 
>> and see whether this is actually something that is
>> warranted and build it to that spec. 
> 
> Please stop trying to put words in my mouth.
> 
> Regardless of what comes out of the ICANN EPDP, this feature will be
> useful to anyone who wants to use it.  There are after all several
> hundred ccTLDs that are not in the EU.  Even if for some reason you
> believe (wrongly) that the GDPR is a bar to implementing this in the
> EU, it isn't in other countries.

If a registrant is living in the EU, or a EU citizen, they would be covered by 
GDPR protections, so its impact is quite significant. As you know, ICANN and 
the industry is seeking to find one compliance model. I do not see why we would 
deviate from that.

All the best,

Niels

> 
> R's,
> John
> 

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint2458 0B70 5C4A FD8A 9488  
   643A 0ED8 3F3A 468A C8B3

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext