Dear Benjamin, Thanks for your review. Please see my feedbacks below. Regards, Linlin
Linlin Zhou From: Benjamin Kaduk Date: 2018-10-24 03:13 To: The IESG CC: regext-chairs; pieter.vandepitte; regext; draft-ietf-regext-org-ext Subject: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-regext-org-ext-09: Discuss 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-ext/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have two points that I would like to discuss. It is more likely than not that at least one of them merely reflects my confusion and is a non-issue, but I would like to get these at least clarified. First, the examples throughout the document use organization identifiers like "myreseller" or "myproxy". This seems to me to be highly confusing, since these IDs are supposed to be server-unique values per organization, and are highly unlikely to be "my" reseller/proxy/etc. for all the entries in the registry. If I understand things correctly, the example IDs should instead be company-name-like values or "random" numbers or similar (or combination thereof). [Linlin] Thank you for pointing out this. To be more consistent with the draft-ietf-regext-org draft, I suggest using the IDs defined in the "org" draft, like "reseller1523" , "registrar1362" or "proxy2935". Second, I am unsure of the semantics relating to role types, especially as they interact with the <update> command. Various aspects of the examples seem to imply that it is only permitted to have at most one organization mapping of a given role type (i.e., one reseller, one proxy, etc.). In particular, the <orgext:chg> element seems to be using the <orgext:id> role attribute to determine which <orgext:id> is being changed (with the new value being provided in the element body), and the <orgext:rem> element is providing <orgext:id> with only the role attribute and no body to identify a specific organization to remove. If this reading of the document is correct, then I would expect the limitation to be called out more clearly, especially as it would seem to prevent a domain owner from (e.g.) using multiple DNS service operators. [Linlin] In the normal business model, for example a domain should have one reseller, one registrar etc. How about adding some text like "One <orgext:id> element is suggested for each role type." in the element description. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 In the business model of domain registration, we usually have 3 roles of entities: a registrant, a registrar and a registry. There may be other roles of entities involved in the domain registration process which are not formally defined, such as resellers, DNS service operators, privacy proxies, etc. nit: Perhaps I am misreading, but are we not going to formally define these entities in the next paragraph (in which case "yet" might be worth adding)? [Linlin] Yes. "...which are not formally defined yet..." An organization mapping object defined in [ID.draft-ietf-regext-org] SHOULD be created first. The organization information specified in this document MUST reference the existing organization identifier. What does "first" refer to? "prior to the use of that object"? [Linlin] Yes. The organizations object should be created prior to using the organization ID for the extension. Maybe I can change the words to be more clear, "Organization object identifiers MUST be known to the server before the organization object can be associated with the EPP object." Section 2 The XML namespace prefix "orgext" 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. [This could probably be written more clearly; see my comment on the companion document] [Linlin] I'll update it to use the full namespace. Section 9 IIRC the authorization model for EPP does not allow arbitrary clients to retrieve information about arbitrary (unrelated) domains. If that's not the case, there would be privacy considerations with respect to exposing the linkages of the organization mappings (and roles). [Linlin] Yes. EPP provides a authentication mechanism which is mentioned in RFC5730. _______________________________________________ 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
