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

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Oct 2018 14:46:00 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-regext-org-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-org/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi, thanks for this work. I have some comments, both substantive and editorial:

*** Substantive Comments ***

§4.1.2: "- A <org:addr>
element contains the following child elements:
+ One, two, or three OPTIONAL <org:street> elements that
contain the organization’s street address."

I take that to mean it must contain at least one. If so, I don't think OPTIONAL
is appropriate; if the elements are optional, they can be left out. simply
saying it contains "1, 2, or 3" would be more appropriate.

§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?

*** Editorial Comments ***

- General:

I'm a little confused by the split in material between draft-ietf-regext-org
and draft-ietf-regext-org-ext, especially how the command mapping and related
info seems to span both documents. It seems a bit reader-unfriendly. But it's
late enough in the process that it's probably not worth changing.

§1, paragraph 1: Please expand EPP on first use in the body. (You do expand it
on the 2nd use in the next paragraph :-) )

§2, 3rd paragraph:  I know we are not consistent about this, but I find the
word “conforming” to be a red flag. Standards track RFCs should be about
interoperability, not conformance. I suggest striking all after “presented”.

§3.2.1: Plural disagreement between “roles and “type” in the second sentence.

§3.3: Plural disagreements between "contacts" and "identifier"

§3.4, 5th paragraph from end: "Organization MUST have only one of these
statuses set"
Please avoid constructions of the form "MUST...only". They can be ambiguous.
Please consider something to the effect of "MUST NOT have more than one" or
"MUST have exactly one". (Same for the "MAY...only" in the next paragraph.)

§4 and subsections: - The text is inconsistent in the use of OPTIONAL for
optional elements. Many are labeled as optional, but some with descriptions
along the lines of "zero or more" are not labeled OPTIONAL when they clearly
are. I don't have a strong opinion which way to go, but please be consistent.

§4.1.1:
- "When a <check> command has been processed successfully, the EPP
<resData> element MUST contain a child <org:chkData> element"
That MUST seems more like a statement of fact. (This pattern occurs several
times.) - "an OPTIONAL "lang" attribute MAY be present" OPTIONAL and MAY are
redundant.

- Command mappings in general: The text is inconsistent in the use of OPTIONAL
for optional elements. Many are labeled as optional, but some with descriptions
along the lines of "zero or more" are not labeled OPTIONAL when they clearly
are. I don't have a strong opinion which way to go, but please be consistent.

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 24 Oct 2018 18:05:25 +0800

Dear Ben,
Thanks for your review. Please see my feedbacks below with [Linlin].

Regards,
Linlin

Linlin Zhou
 
From: Ben Campbell
Date: 2018-10-24 05:46
To: The IESG
CC: regext-chairs; pieter.vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Ben Campbell's No Objection on draft-ietf-regext-org-11: (with COMMENT)
Ben Campbell has entered the following ballot position for
draft-ietf-regext-org-11: No Objection

 

 
§4.1.2: "- A <org:addr>
 
I take that to mean it must contain at least one. If so, I don't think OPTIONAL
is appropriate; if the elements are optional, they can be left out. simply
saying it contains "1, 2, or 3" would be more appropriate.
[Linlin] Yes, good point. I'll remove "optional".
 
§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.

- General:
 
[Linlin] I can have some explanations for the two documents. draft-ietf-regext-org is a new EPP organization object with some role values. draft-ietf-regext-org-ext has defined an extension in exsiting EPP objects such as domain in RFC5731, host in RFC5732 and contact in RFC5733. These objects can link with an orgnization ID created in draft-ietf-regext-org.
 
[Linlin] Yes, thank you.
 
[Linlin] OK.
 
§3.2.1: Plural disagreement between “roles and “type” in the second sentence.
[Linlin] Yes. "An organization could have multiple roles with different role types. 
 
§3.3: Plural disagreements between "contacts" and "identifier"
[Linlin] Yes. "All EPP contacts are identified by server-unique identifiers."
 
[Linlin] OK. Thank you for your suggestions.
 
[Linlin] I'll double check the text.
 
§4.1.1:
- "When a <check> command has been processed successfully, the EPP
<resData> element MUST contain a child <org:chkData> element"
That MUST seems more like a statement of fact. (This pattern occurs several
times.) - "an OPTIONAL "lang" attribute MAY be present" OPTIONAL and MAY are
redundant.
[Linlin] These "MUST" sentences are trying to be compliant with the EPP RFCs and other EPP extensions.
"an OPTIONAL "lang" attribute may be present".
 
[Linlin] Thank you. I'll double check the text.

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2018 12:32:34 -0500

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 <[email-masked]> wrote:
> 

[...]

> [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 b…

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?

[...]

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 25 Oct 2018 09:50:17 +0800

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.

Regards,
Linlin

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:

Thanks!

Ben.

[...]

[...]

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2018 21:08:53 -0500

> On Oct 24, 2018, at 8:50 PM, Linlin Zhou <[email-masked]> wrote:
> 
> Dear Ben,

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:[email-masked]>
> Date: 2018-10-25 01:32
> To: Linlin Zhou <mailto:[email-masked]>
> CC: iesg <mailto:[email-masked]>; regext-chairs <mailto:[email-masked]>; Pieter Vandepitte <mailto:[email-masked]>; draft-ietf-regext-org <mailto:[email-masked]>; regext <mailto:[email-masked]>
>> On Oct 24, 2018, at 5:05 AM, Linlin Zhou <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> 
> [...]
> 
>>

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 29 Oct 2018 10:01:47 +0800

Dear Ben,
Thanks for your suggestions. I think I can add this paragraph in the section of security consideration.

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, which is specified in RFC5733. The security considerations described in[RFC5730] or those caused by the protocol layers used by EPP will apply to this specification as well.

Regards,
Linlin

Linlin Zhou
 
From: Ben Campbell
Date: 2018-10-25 10:08
To: Linlin Zhou

Dear Ben,

Hi,

Thanks!

Ben.

Regards,
Linlin

Linlin Zhou
 
From: Ben Campbell
Date: 2018-10-25 01:32
To: Linlin Zhou

Thanks!

Ben.

[...]

[...]