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

"Linlin Zhou" <> Wed, 24 October 2018 10:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD2C8130DC3; Wed, 24 Oct 2018 03:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WdXy78FEB1S6; Wed, 24 Oct 2018 03:04:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A2CC5130E82; Wed, 24 Oct 2018 03:04:28 -0700 (PDT)
Received: from zll (unknown []) by (Coremail) with SMTP id AQAAf0AZIPykQ9BbwywCAA--.2693S2; Wed, 24 Oct 2018 18:04:20 +0800 (CST)
Date: Wed, 24 Oct 2018 18:05:25 +0800
From: "Linlin Zhou" <>
To: ben <>, iesg <>
Cc: 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_NextPart107512747370_=----"
X-Coremail-Antispam: 1UD129KBjvJXoWxuw4fJr1xuw4fKr4DAw1kZrb_yoW7GFW3pF WfGw1xGws8Jw1UJw1Iv3W8Xr1Y9wn3AFWUJFy3Xr4vyas8Cas2yr1ayanYyFyUuryrX3Wj q34j9ryqgw12yrJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUHFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG62kEwI0E Y4vaYxAvb48xMc02F40E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAFz48EcVAYj2 1lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkE bVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0F y26I8I3I1lc7CjxVAaw2AFwI0_JF0_Jw1lc2xSY4AK67AK6r4DMxAIw28IcxkI7VAKI48J MxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwV AFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv2 0xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4 v20xvaj40_Wr1j6rW3Jr1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x02 67AKxVW8JVW8Jr1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxUyw05DUUUU
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: Wed, 24 Oct 2018 10:04:35 -0000

Dear Ben,
Thanks for your review. Please see my feedbacks below with [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
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
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
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.
[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
[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.
*** 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.
[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.
§1, paragraph 1: Please expand EPP on first use in the body. (You do expand it
on the 2nd use in the next paragraph :-) )
[Linlin] Yes, thank you.
§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”.
[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."
§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.)
[Linlin] OK. Thank you for your suggestions.
§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.
[Linlin] I'll double check the text.
- "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
[Linlin] These "MUST" sentences are trying to be compliant with the EPP RFCs and other EPP extensions.
"an OPTIONAL "lang" attribute may be present".
- 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.
[Linlin] Thank you. I'll double check the text.
regext mailing list