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. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
