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

Ben Campbell <ben@nostrum.com> Tue, 23 October 2018 21:46 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: regext@ietf.org
Delivered-To: regext@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CF9130DD7; Tue, 23 Oct 2018 14:46:00 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-regext-org@ietf.org, Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be>, regext-chairs@ietf.org, pieter.vandepitte@dnsbelgium.be, regext@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154033116074.31409.10404721139795648969.idtracker@ietfa.amsl.com>
Date: Tue, 23 Oct 2018 14:46:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/IGsExSYX3wksIbH6AV3-WxKZLyc>
Subject: [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
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: Tue, 23 Oct 2018 21:46:01 -0000

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.