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

Ben Campbell <ben@nostrum.com> Thu, 25 October 2018 02:09 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400B41292AD; Wed, 24 Oct 2018 19:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.867
X-Spam-Level:
X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KZHHkbHs78A; Wed, 24 Oct 2018 19:09:57 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513DA126BED; Wed, 24 Oct 2018 19:09:57 -0700 (PDT)
Received: from [10.0.1.27] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w9P28s6h022348 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 24 Oct 2018 21:08:55 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.27]
Content-Type: multipart/signed; boundary="Apple-Mail=_C6A74D27-FC23-4A37-8727-B574BE2ACB39"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Ben Campbell <ben@nostrum.com>
X-Priority: 3
In-Reply-To: <2018102509501609880949@cnnic.cn>
Date: Wed, 24 Oct 2018 21:08:53 -0500
Cc: iesg <iesg@ietf.org>, regext-chairs <regext-chairs@ietf.org>, Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>, draft-ietf-regext-org <draft-ietf-regext-org@ietf.org>, regext <regext@ietf.org>
Message-Id: <F5474CB9-96A6-449F-A989-950CF11860E6@nostrum.com>
References: <154033116074.31409.10404721139795648969.idtracker@ietfa.amsl.com> <20181024180525369910221@cnnic.cn> <B77EF5B6-00F9-4CC4-9E10-B48595658748@nostrum.com> <2018102509501609880949@cnnic.cn>
To: Linlin Zhou <zhoulinlin@cnnic.cn>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/0sU-zpRl9duI_xJrYUcm6AvVlzI>
Subject: Re: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: (with COMMENT)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2018 02:09:59 -0000


> On Oct 24, 2018, at 8:50 PM, Linlin Zhou <zhoulinlin@cnnic.cn> wrote:
> 
> 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.

Hi,

Your last paragraph above is the sort of thing I had in mind. It would be helpful to include it in the draft. I

Thanks!

Ben.

> 
> Regards,
> Linlin
> Linlin Zhou
> 
> From: Ben Campbell <mailto:ben@nostrum.com>
> Date: 2018-10-25 01:32
> To: Linlin Zhou <mailto:zhoulinlin@cnnic.cn>
> CC: iesg <mailto:iesg@ietf.org>; regext-chairs <mailto:regext-chairs@ietf.org>; Pieter Vandepitte <mailto:pieter.vandepitte@dnsbelgium.be>; draft-ietf-regext-org <mailto:draft-ietf-regext-org@ietf.org>; regext <mailto:regext@ietf.org>
> 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:
> 
> Thanks!
> 
> Ben.
> 
>> On Oct 24, 2018, at 5:05 AM, Linlin Zhou <zhoulinlin@cnnic.cn <mailto:zhoulinlin@cnnic.cn>> 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
>> section?
>> [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?
> 
> 
> [...]