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