On Thu, Oct 25, 2018 at 11:29:41AM +0800, Linlin Zhou wrote: > 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".
Excellent; thank you! > 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. I don't think that addresses my core concern (though it is probably worth doing in its own right). In particular, if it is allowed by the protocol/registry to have more than one <orgext:id> element of a given role type, then several of the protocol exchanges this document defines within <update> are not fully defined in an interoperable fashion. For example, what if I receive a <orgext:chg><orgext:id role="dns-operator>dns872</orgext:id></orgext:chg> and there are currently two dns-operators defined? Do I remove both existing entries and add the one new one? Do I remove just one existing entry and replace it with the new one? If the latter, how do I pick which one is to be removed? I just don't see how the operation is fully specified for these cases. > > ---------------------------------------------------------------------- > 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." I think that helps; thank you. -Benjamin > 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
