Ballot for draft-ietf-regext-org
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
This is a well written document, but I am concerned about missing references for various syntactic elements that you use. Having proper references will save developers time and will improve interoperability. The same issue in at least 3 places in the document, I am mentioning the first one below. In 4.1.1: o An OPTIONAL <org:reason> element that may be provided when an object cannot be provisioned. If present, this element contains server-specific text to help explain why the object cannot be provisioned. This text MUST be represented in the response language previously negotiated with the client; an OPTIONAL "lang" Please either point to the Language tag RFC 5646/BCP 47 or point to another RFC which defines the "lang" attribute. attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en"(English). 4.1.2. EPP <info> Command o Zero to two <org:postalInfo> elements that contain postal-address information. Two elements are provided so that address information can be provided in both internationalized and localized forms; a "type" attribute is used to identify the two forms. If an internationalized form (type="int") is provided, element content MUST be represented in a subset of Unicode in the range U+0020 - U+007E. If a localized form (type="loc") is provided, element content MAY be represented in unrestricted UTF- 8. The <org:postalInfo> element contains the following child elements: [snip] + An <org:cc> element that contains the organization's country code. Please add the correct reference for country codes. I believe you want to reference alpha-2 country codes from ISO 3166. (There are also alpha-3 country codes.) Alternative you can just reference a section from RFC 5733. o An OPTIONAL <org:email> element that contains the organization's email address. Please point to specific format for email addresses (there is RFC 5321 format and RFC 5322 format. They are not identical.) Alternative you can just reference a section from RFC 5733. o An OPTIONAL <org:url> element that contains the URL to the website of the organization. Please add a reference to RFC 3986 or to one of HTTP RFCs if you want to restrict this to https: or http: One possible way of addressing all of the above is to add a few sentences with references to the "Conventions Used in This Document" section.
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.
Some of the element descriptions (e.g., <org:postalInfo>) appear to be duplicated in several places and are also rather long in prose form. Is there value in attempting to consolidate the structural definition to a single place in the document and just refer to that structure from the places where it can appear? Section 1 There are many entities, such as registrars, resellers, DNS service operators, or privacy proxies involved in the domain registration business. These kind of entities have not been formally defined as an object in EPP which will be specified as "organization" in this document. nit: run-on sentence. I suggest: These kind of entities have not been formally defined as having an object in EPP. This document provides a way to specify them as "organization" entities. Section 2 The XML namespace prefix "org" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. I suggest mentioning more explicitly that "org" is used in the examples as shorthand for the full namespace "urn:ietf:params:xml:ns:epp:org-1.0"; draft-ietf-regext-allocation-token would be a fine example to look at. Section 3.4 Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". The "hold" and "terminated" status values are server-managed when the organization has no parent identifier [Section 3.6] and otherwise MAY be client- managed based on server policy. The list/descriptions that follows shows several that don't start with "client"/"server", including some not mentioned here. Are we supposed to assume that these "unprefixed" values are also server-managed? o ok: This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed. I guess this is intended to be parsed as "(pending operations) or (prohibitions)", but could also be parsed as "pending (operations or prohibitions)". Perhaps "operations pending or active prohibitions" is less prone to misreading. In general, the sort of "all combinations are permitted, except for these restrictions" approach taken here can lead to some non-sensical combinations, if insufficient care is taken by the document authors. I did not attempt to validate all possible combinations, but do note that (e.g.) we make statements about "linked" in combination with "ok" and "client/serverLinkProhibited", but not about "linked" in combination with "terminated" or several other status values. The first of those cases serves as a limitation on "ok", and the second would seem to be intended to clarify that an apparent conflict of status is permissible, and so it may well be okay to leave as the default ("everything goes") for other combinations, but I hope that the WG has done a careful analysis here. It may also be useful to list what considerations were used in this analysis, in case there is ever a need to add a new status value (in which case the analyses would need to be performed anew for the added value(s)). Section 3.4 (Same comment as above re "pending operations or prohibitions") Section 3.6 Take a reseller organization, for example, the parent identifier is not defined for the top level reseller, namely the registrar of the registry. [...] nit: this also looks like a run-on sentence; I'd suggest something like "The case of reseller organizations provides an example. The parent identifier is not defined [...]" Loops MUST be prohibited. For example: if organization A has B as its parent identifier, organization B should not have organization A as its parent identifier. The same is true for larger loops involving three or more organizations. I'd suggest s/should not/cannot/ Section 4.1.1 In addition to the standard EPP command elements, the <check> command MUST contain an <org:check> element. This element or its ancestor element MUST identify the organization namespace. [...] "the organization namespace" is perhaps ambiguous; am I correct in inferring that this refers to the full "urn:ietf:params:xml:ns:epp:org-1.0" namespace value as assigned to the "org" short name? (I'll refrain from repeating this comment every time it applies.) Section 4.1.2 The <org:addr> restrictions seem somewhat contrived/artificially restricted; for example, there are postal addresses in the US with no associated city. Whether an organization would want to use such an address as its contact location is another question, but I don't have a clear model of what sort of constraints are intended to be applied by this element. Section 4.2.1 Just to check my understanding, the <org:creData> contains only a short list of fields because the server is required to either respect the various <org:role>, <org:postalInfo>, etc. in the <org:create> request or to return an error? That is, the client would not need to immediately perform an <info> query to confirm the status of the organization object at the server. Section 4.2.2 Is there value in an example of the 2305-error response? Section 4.2.5 The elements in <org:add>/<org:rem> vs. <org:chg> seem to be disjoint sets; what factors went into deciding to split them this way? Section 4.3 The status of the corresponding object MUST clearly reflect processing of the pending action. [...] It's not entirely clear how this sentence is to be interpreted. From context, I assume that the intent is that <info> queries and similar must report that the appropriate pendingFoo status values, but a literal reading would seem to have this sentence be a requirement that the server change what it reports for the object status, once the action is actually taken. (Which is also something desired, but arguably already required by other text.) The status of the organization object after returning this response MUST include "pendingCreate". The server operator reviews the request offline, and informs the client of the outcome of the review either by queuing a service message for retrieval via the <poll> command or by using an out-of-band mechanism to inform the client of the request. I don't think the "either" is appropriate; the earlier text *requires* the service message, and allows for additional optional notification mechanisms. (side question: what's the mnemonic for "pan" in "panData"? "pending action"? Ah, the full schema suggests "pending action notification". Also, why is the top-level a "pan" prefix but the children just "pa"?) Section 7.3.1 Registrant Name: For Standards Track RFCs, state "IESG". For others, give the name of the responsible party. Just to clarify, is the intended behavior for non-standards-track IETF-stream RFCs that the registrant is one of the RFC authors? I could see a case that "IESG" would work for all IETF-stream documents, not just standards-track ones. Registrant Contact Information: an email address, postal address, or some other information to be used to contact the registrant. Perhaps a side note, but postal address in particular has come up frequently in GDPR discussions, with the question of whether it is either needed or useful. Section 9 This document is pretty boring from the security perspective (to be clear: that is a good thing!). The only thing that came to mind is that in one of the examples, we show the client asking for <org:id>s of res1523, re1523, and just 1523. Only "re1523" was in use, indicating that the other two would be free for new allcations. In some contexts this kind of "very similar looking" identifier can be problematic, especially when a human is called upon to verify or compare the value(s). From what I understand of EPP usage, that doesn't seem likely to be a concern here, but I mention it in case my understanding is incorrect or incomplete.
Thank you for addressing my DISCUSS