Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

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