Subject: Re: [regext] I-D Action: draft-ietf-regext-verificationcode-01.txt

From: "Gould, James" <[email-masked]>
Date: Tue, 18 Apr 2017 13:00:25 +0000

Niels comment in Chicago was related to the reseller drafts.  Neils, if you have proposed text to add to draft-ietf-regext-verificationcode, please share it publically or privately.  

Thanks,
 
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com <http://verisigninc.com/> 

On 4/18/17, 8:41 AM, "regext on behalf of Hollenbeck, Scott" <[email-masked] on behalf of [email-masked]> wrote:

    > -----Original Message-----
    > From: regext [mailto:[email-masked]] On Behalf Of Niels ten Oever
    > Sent: Tuesday, April 18, 2017 8:31 AM
    > To: [email-masked]
    > Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-
    > verificationcode-01.txt
    >
    > Hi all,
    >
    > I just found out that this draft standards is already being approved by
    > ICANN since February, which somehow seems a bit the wrong way around:
    >
    > https://www.icann.org/en/system/files/correspondence/papac-to-kane-
    > 27feb17-en.pdf
    >
    > I brought up on this list and in the past two sessions that this document
    > would really benefit from Privacy Considerations (RFC6973).
    >
    > Not only because it is a good thing to do, but also because if we want
    > these practices to exist for some time they will need to abide by privacy
    > regulations (such as the upcoming GODR [0]).
    
    Niels, if I remember correctly James Gould asked you at the Chicago meeting if you could help with proposed text to be added to the document, and I think you agreed. Have you had a chance to work with him to come up with that text?
    
    Scott
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 18 Apr 2017 15:29:28 +0200

Hi James,

You're right. In Berlin I mentioned it in relation to the verification
code draft (and brought up the statement about it [0]), but similar
there are definitely also considerations for the resellers draft.

Question is: should we create privacy considerations per draft, or would
it make more sense to make a draft with Privacy Considerations for EPP
(similar to RFC7819 did for DHCP).

Best,

Niels

[0]
https://www.article19.org/resources.php/resource/38577/en/corporate-actors-must-not-facilitate-human-rights-violations-through-new-chinese-rules

On 04/18/2017 03:00 PM, Gould, James wrote:
> Niels comment in Chicago was related to the reseller drafts.  Neils,
> if you have proposed text to add to
> draft-ietf-regext-verificationcode, please share it publically or
> privately.
> 
> Thanks,
> 
> —
> 
> JG
> 
> 
> 
> James Gould Distinguished Engineer [email-masked]
> 
> 703-948-3271 12061 Bluemont Way Reston, VA 20190
> 
> On 4/18/17, 8:41 AM, "regext on behalf of Hollenbeck, Scott"
> <[email-masked] on behalf of [email-masked]>
> wrote:
> 
>> -----Original Message----- From: regext
>> [mailto:[email-masked]] On Behalf Of Niels ten Oever Sent:
>> Tuesday, April 18, 2017 8:31 AM To: [email-masked] Subject:
>> [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext- 
>> verificationcode-01.txt
>> 
>> Hi all,
>> 
>> I just found out that this draft standards is already being
>> approved by ICANN since February, which somehow seems a bit the
>> wrong way around:
>> 
>> I brought up on this list and in the past two sessions that this
>> document would really benefit from Privacy Considerations
>> (RFC6973).
>> 
>> Not only because it is a good thing to do, but also because if we
>> want these practices to exist for some time they will need to abide
>> by privacy regulations (such as the upcoming GODR [0]).
> 
> Niels, if I remember correctly James Gould asked you at the Chicago
> meeting if you could help with proposed text to be added to the
> document, and I think you agreed. Have you had a chance to work with
> him to come up with that text?
> 
> Scott
> 
> _______________________________________________ regext mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/regext
> 
> 

-- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

PGP fingerprint    8D9F C567 BEE4 A431 56C4
                     678B 08B5 A0F2 636D 68E9

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 18 Apr 2017 13:47:25 +0000

(Sorry, resending due to a corporate mailer encryption setting user error on my part).

> From: Niels ten Oever [mailto:[email-masked]]
> Sent: Tuesday, April 18, 2017 9:29 AM
> To: Gould, James <[email-masked]>; Hollenbeck, Scott
> <[email-masked]>; [email-masked]' <[email-masked]>
> code draft (and brought up the statement about it [0]), but similar there
> are definitely also considerations for the resellers draft.

Could you elaborate on that, please? The reseller (soon to be generic 
organization, I believe) draft(s) describe a means of exchanging information 
to identify an organization. Which bits of information do you see having human 
rights considerations?

> (similar to RFC7819 did for DHCP).

I don't know that I can answer that question without a better explanation of 
the kinds of things to be considered. I *can* see issues associated with 
personal privacy and the publication of contact information in WHOIS and/or 
RDAP (which points towards considerations for a document like RFC 5733), but 
where do you see considerations for a document like RFC 5732 in which there is 
no exchange of information associated with humans?

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 20 Apr 2017 00:14:41 +0200

Hi Scott,

> to identify an organization. Which bits of information do you see having human 

Thanks for bringing up human rights considerations here. If I understand
 draft-ietf-regext-reseller-01 correctly, one could force a customer in
country X to have a 'reseller:name type="loc" in country X' which could
impact the ability of a user to acquire a domain.

It would help to understand the reason of adding this to the spec.

> no exchange of information associated with humans?

It depends whether we're thinking about privacy consideration, or human
rights considerations as you brought up. If we focus on privacy
considerations, then focusing on RFCs that deal with PII makes most
sense, but other drafts defintely have an impact on freedom of assembly,
association, etc.

Best,

Niels

-- 
Niels ten Oever
Head of Digital

Article 19
www.article19.org

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 20 Apr 2017 13:35:37 +0000

> Sent: Wednesday, April 19, 2017 6:15 PM
> To: Hollenbeck, Scott <[email-masked]>; Gould, James
> <[email-masked]>; [email-masked]' <[email-masked]>
> >> You're right. In Berlin I mentioned it in relation to the
> >> verification code draft (and brought up the statement about it [0]),
> >> but similar there are definitely also considerations for the resellers
> draft.
> >
> > organization, I believe) draft(s) describe a means of exchanging
> > information to identify an organization. Which bits of information do
> > you see having human rights considerations?
> >
>

That specific field is used to identify the name of the reseller business in a 
localized (a representation commonly understood by people living in some local 
area, such as the German word "hund" vs. the English word "dog" for people 
living in Berlin) form. It's included in the spec because the name of a 
reseller entity (or any other organizational entity) is what people typically 
see when interacting with these entities. The name is thus very useful 
information.

> impact the ability of a user to acquire a domain

Are you implying that the ability to acquire any domain I want is a fundamental right? If so, we are in for some interesting debates. Here's a very specific example:

DENIC has a cooperative membership structure that allows members to provide services to resellers (see link below). A reseller of .de domains could very well be identified with a 'reseller:name type="loc" in Germany', and someone who wishes to register a .de domain must (is forced to?) do so through a member of the cooperative or through a reseller of a member. Is this a human rights restriction? I personally don't think it is, even though I am in fact restricted in my ability to acquire a .de domain.

> >> Question is: should we create privacy considerations per draft, or
> >> would it make more sense to make a draft with Privacy Considerations
> >> for EPP (similar to RFC7819 did for DHCP).
> >
> > I don't know that I can answer that question without a better
> > explanation of the kinds of things to be considered. I *can* see
> > issues associated with personal privacy and the publication of contact
> > information in WHOIS and/or RDAP (which points towards considerations
> > for a document like RFC 5733), but where do you see considerations for
> > a document like RFC 5732 in which there is no exchange of information
> associated with humans?
>
> considerations, then focusing on RFCs that deal with PII makes most sense,
> but other drafts defintely have an impact on freedom of assembly,
> association, etc.

I don't understand why you've drawn a distinction between "privacy consideration, or human rights considerations" as quoted above. Privacy is addressed in Section 6.2.2 of draft-irtf-hrpc-research, so there appears to be a relationship. Anyway, I agree in principle that we need to be concerned about privacy considerations. I could still use help with specific examples where you see impacts on freedom of assembly or association.

Scott

* 
https://www.denic.de/fileadmin/public/documents/Media/DENIC-Factsheet_Web.pdf