Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: (with COMMENT)

"Linlin Zhou" <> Thu, 25 October 2018 01:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44A64130DE9; Wed, 24 Oct 2018 18:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sZnnimctpxWO; Wed, 24 Oct 2018 18:49:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4C330130DD7; Wed, 24 Oct 2018 18:49:17 -0700 (PDT)
Received: from zll (unknown []) by (Coremail) with SMTP id AQAAf0BJUPAXIdFbHV0CAA--.2865S2; Thu, 25 Oct 2018 09:49:11 +0800 (CST)
Date: Thu, 25 Oct 2018 09:50:17 +0800
From: "Linlin Zhou" <>
To: ben <>
Cc: iesg <>, regext-chairs <>, "Pieter Vandepitte" <>, draft-ietf-regext-org <>, regext <>
References: <>, <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart231018148300_=----"
X-Coremail-Antispam: 1UD129KBjvJXoW7Cw4rWF13CrWrtFyUCr4rXwb_yoW8Crykpa 9agwn2vas5J347CwnF9ayxu34FkrZY9r4DAas3Gr1DCwn8G3WIk3WSyFnrCFy0934UJw1D Zryagrn0gr1kurJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUHIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAa z4v26cxKscIFY7kG0wAqx4xG6xAIxVCFxsxG0wAqx4xG6I80eVA0xI0YY7vIx2IE14AGzx vEb7x7McIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC 6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67 k04243AVC20s07Mx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_KwCF04k20xvY0x0E wIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E74 80Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41lIxAIcVC0 I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04 k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY 1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVFxhVjvjDU0xZFpf9x07jOuciUUU UU=
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <>
Subject: Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Oct 2018 01:49:22 -0000

Dear Ben,
Maybe I did not make this item clarified. I'd like to have some more explanations. You are right that the EPP organization object may have a <contact> element, but this is not a required information. There may be some possibilities as follows,
1. If the organizations do not want to provide this information to protect the privacy, the <contact> could be empty.
2. If the organizations have no issues on the privacy, they can input the contact identifier created according to RFC5733.
    a. In RFC5733, required info including contact id, contact name, city, country code, email and authentication info.
    b. Optional info including contact organization, street, state or province, postal code, voice, fax and disclose elements choices.
"Authorization information is REQUIRED to create a contact object. ......Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption 
mechanisms to provide privacy services." was specified in RFC5733.

The organization object may have personally identifiable information, such as <org:contact>. This information is not a required element in this document which can be provided on a voluntary basis. If it is provided, both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy services, whichi is specified in RFC5733.


Linlin Zhou
From: Ben Campbell
Date: 2018-10-25 01:32
To: Linlin Zhou
CC: iesg; regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: (with COMMENT)
Thanks for your response. It all looks good, except for one item below:



On Oct 24, 2018, at 5:05 AM, Linlin Zhou <>; wrote:


§9: The org element can contain contact information, possibly including
personally identifiable information of individuals. Doesn’t this have privacy
implications that should be discussed here or in a privacy considerations
[Linlin] This document is an object extension of EPP that follows all the security requirements for EPP. We do not hope to add any more secure considerations in this document. So this element can be "zero" if you do not like to provide.

I don’t understand how your answer addresses my question. As far as I can tell, this document creates a new object that can contain personally identifiable information (PII). Is that incorrect?

Is there text in EPP that already talks about PII that can be cited?