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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Oct 2018 12:13:39 -0700

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).

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.

----------------------------------------------------------------------
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)?

   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"?

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]

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).

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 25 Oct 2018 11:29:41 +0800

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

 

[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".

[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.

Section 1

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..."

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

[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
 
[Linlin] Yes. EPP provides a authentication mechanism which is mentioned in RFC5730.

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 Oct 2018 12:28:16 -0500

> https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/

Excellent; thank you!

> [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."…

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.

I think that helps; thank you.

-Benjamin

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 30 Oct 2018 10:16:05 +0800

Dear Benjamin,
I've included my feedbacks inline and removed the clarified items.

Regards,
Linlin

Linlin Zhou

 
 
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.
 [Linlin] We have discussed the error cases, but may lack of this situation.
If there are already multiple IDs exist with a particular role, I suggest not changing the object and returning an error code 2305 which means "Object association prohibits operation".
Maybe some words like "An attempt to change an organization ID with a particular role value, when multiple IDs exist with the same role value, does not change the object at all. A server SHOULD notify clients that object relationships need to be checked by sending a 2305 error response code. "

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 30 Oct 2018 20:05:07 -0500

> If there are already multiple IDs exist with a particular role, I suggest not changing the object and returning an error code 2305 which means "Object association prohibits operation".

That seems reasonable to me, given that we expect this situation to be
uncommon, and a combination of <orgext:add> and <orgext:rem> should allow
the desired changes to be made more precisely.

> Maybe some words like "An attempt to change an organization ID with a particular role value, when multiple IDs exist with the same role value, does not change the object at all. A server SHOULD not…

I would suggest a little more lead-in text, maybe like:

It is expected to generally be the case that any given object will have at
most one associated organization ID for any given role value, though the
registry semantics do permit two or more associated organizations for a
given role.  In such cases, certain <orgext:chg> and <orgext:rem>
elements may not uniquely specify an operation to perform (e.g., which of
two organizations to replace via <orgext:chg>, or which of two
organizations to remove via an <orgext:rem> with empty body).  An attempt
to change an organization ID with a particular role value, when multiple
IDs exist with the same role value, does not change the object at all. A
server SHOULD notify clients that object relationships need to be checked
by sending a 2305 error response code.

Feel free to edit as you see fit; my only concern is that the expected
behavior is specified, not how it is written.  (In particular, given how
uncommon this situation is expected to be, the multiple examples may be
overkill.)

-Benjamin

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 31 Oct 2018 14:19:45 +0800

Dear Benjamin,
Thanks for your input. We believe that relationship between an object and an organization should be 1-to-1, one organization ID with just one role. 1-to-many is an exception for the organization extension. Indeed that is our concern, "the multiple examples may be overkill". Many thanks.
 
Regards,
Linlin

Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 09:05
To: Linlin Zhou
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
Subject: Re: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)

 

 
-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Oct 2018 07:43:21 -0500

Dear Linlin,

> Thanks for your input. We believe that relationship between an object and an organization should be 1-to-1, one organization ID with just one role. 1-to-many is an exception for the organization ex…

I won't object to requiring the 1-to-1 mapping, as the impact of the
restriction seems minor.  I am not entirely sure where the best place to
add some text that clarifies this restriction would be; perhaps in Section
4.2.1 where we describe the <orgext:id> elements in <create>?  (I assume
that the formal syntax does not provide for a maxOccurs that applies
per-type.)  It may also be worth a (non-normative) reminder in the <update>
description that the semantics of <orgext:chg> are well-defined because
there is only one entry per role value, but I'm not sure about that.

Thanks,

Benjamin

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 1 Nov 2018 11:28:10 +0800

Dear Benjamin,
I found that following sections may be the proper place to restrict the 1-to-1 mapping. I think we can have restrictions in section 3.1 only or in 3.1&4.2.1&4.2.5. I've not decided which one is better and hope to have others' suggestions.

1. In section 3.1 Organization Identifier, add sentences at the end of this paragraph.
A "role" attribute is used to represent the relationship that the organization has to the EPP object. Any given object MUST have at most one associated organization ID for any given role value.

2. In section 4.2.1,
One or more <orgext:id> elements that contain the identifier of the organization. The "role" attribute is used to represent the relationship that the organization has to the object. Any given object MUST have at most one associated organization ID for any given role value. See Section 7.3 in [ID.draft-ietf-regext-org] for a list of values.

3. In section 4.2.5
One or more <orgext:id> elements that contain the identifier of the organization. The "role" attribute is used to represent the relationship that the organization has to the object. Any given object MUST have at most one associated organization ID for any given role value. See Section 7.3 in [ID.draft-ietf-regext-org] for a list of values. 

If we have the restrictions, the 1-to-multiple mapping cases are not necessary to be specified in this document.

Regards,
Linlin

Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-31 20:43
To: Linlin Zhou
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org-ext
Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-org-ext-09: (with DISCUSS and COMMENT)
Dear Linlin,

 
Thanks,
 
Benjamin