Subject: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Oct 2018 10:38:42 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-org-11: No Objection

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 24 Oct 2018 17:09:07 +0800

Dear Benjamin,
Thanks for your review. Please find my feedbacks below with [Linlin].

Regards,
Linlin

Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-24 01:38
To: The IESG
CC: regext-chairs; pieter.vandepitte; draft-ietf-regext-org; regext
Subject: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)
Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-org-11: No Objection

 
 
[Linlin] This document borrowed the text structure from RFC5731, RFC5732 and RFC5733 of EPP. I think the intension of having some duplicated descriptions is for users' easy reading. When seeing the examples, they do not have to scroll up and down to find the elements definitions. Some descriptions are a little different, although <org:postalInfo> elements appear to be duplicated. Such as, "One or more <org:status> elements" in <info> response and  "Zero or more <org:status> elements" in <create> command. Of course putting all the elements definitions in a section is a concise way for the document structure.

Section 1

[Linlin] OK.
 
Section 2

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.
[Linlin] Yes. "The XML namespace prefix "org" is used for the namespace "urn:ietf:params:xml:ns:epp:org-1.0".
 
Section 3.4

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?
[Linlin] Yes, other status values that do not begin with either "client" or "server" are server-managed. I'll add this setence to clarify.

[Linlin] OK.
 
[Linlin] The combination statuses of "ok", "linked" and "client/serverlinkProhibited" are allowed in the first example. But "The organization which has been terminated MUST NOT be linked." which is mentioned in the "terminated" definition. So the server will provide service to update the "linked" status for those terminated organizations.
We listed the conflicted combinations of the statuses. Other status combinations not expressly prohibited may be used.
 
Section 3.4
 
(Same comment as above re "pending operations or prohibitions")
[Linlin] I think you mean the "ok" definition in section 3.5. This will be modified as "operations pending or active prohibitions" as well.
 
Section 3.6

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 [...]"
[Linlin] OK. "The case of reseller organizations provides an example. The parent identifier is not defined for the top level reseller, namely the registrar of the registry"

[Linlin] Yes.
 
Section 4.1.1

"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.)
[Linlin] Yes, I'll add the full namespace. 
"This element or its ancestor element MUST identify the organization namespace "urn:ietf:params:xml:ns:epp-1.0"."
 
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.
[Linlin] Sorry that I am not familiar with the US address. If no city is available, how about municipal or county information?
This <postalInfo> element have the same structure with the <postalInfo> defined in RFC5733. This is an existing XML schema in the running EPP system. Domain registries and registrars have already implemented it. Acturally this is an optional info here. You can have no <postalInfo>, one <postalInfo> or two <postalInfo> elements.
 
Section 4.2.1
 
[Linlin] The result codes which are defined in RFC5730 will return in the response. Client do not need to perform <info> immediately. If the command has been processed successfully, client will recieve "1000". If fails, client may recieve such as  "2001" means "Command syntax error" to give a hint.
 
Section 4.2.2
 
Is there value in an example of the 2305-error response?
[Linlin] I think the example of 2305 error would like follows,
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> 
S: <response> 
S: <result code="2305"> 
S: <msg lang="en">Object association prohibits operation</msg> 
S: </result> 
S: <trID> 
S: <clTRID>ABC-12345</clTRID> 
S: <svTRID>54321-XYZ</svTRID> 
S: </trID> 
S: </response> 
S:</epp>
 
This example is much the similar with the existing one except for the "code" and "msg".

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?
[Linlin] From my understanding, <org:add>/<org:rem> are used for the one-multiple relations. And <org:chg> is used for the one-one replacement.
 
Section 4.3

 [Linlin] The "transform command" is mentioned in the previous text. So the status means "status in the response", no need to perform the <info> query. So how about changin like "The status in the response of the corresponding object...".

I don't think the "either" is appropriate; the earlier text *requires* the
service message, and allows for additional optional notification
mechanisms.
 [Linlin] This <poll>mechanism is supported in section 2.9.2.3 of RFC5730. So this is a easy and convinient way to inform the clients.

(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"?)
[Linlin] This section was adopted from RFC5731. 
I think "pan" is used to tell clients the following messages are "pending action notification". But for a particular element, this is just a "pending action" tag, not the notification message.
 
Section 7.3.1

[Linlin] OK.

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.
 [Linlin] This element can be "zero" if you do not like to provide.
Section 9
 
[Linlin] Thank you.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Oct 2018 13:34:08 -0500

(Also inline)

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

It sounds like it is not worth making this change for this document, then.
Thanks for the background explanation!

> [Linlin] I think you mean the "ok" definition in section 3.5. This will be modified as "operations pending or active prohibitions" as well.

Yes; thank you.

> [Linlin] Sorry that I am not familiar with the US address. If no city is available, how about municipal or county information?

The type of place I'm thinking of would usually be referred to as
"unincorporated DeKalb County" or occasionally "unincorporated Chicago"
with some associated municipal or city information.  (As something of a
side note, I currently reside in Saint Louis city, which is not part of any
county; there is a distinct Saint Louis County that covers the surrounding
areas.  Addresses can be hard; just like (personal) names!)

> This <postalInfo> element have the same structure with the <postalInfo> defined in RFC5733. This is an existing XML schema in the running EPP system. Domain registries and registrars have already i…

I definitely do not want to suggest diverging the definition of
<postalInfo> from RFC5733, so please treat this entire conversation as a
side note with no actions to take.

> [Linlin] The result codes which are defined in RFC5730 will return in the response. Client do not need to perform <info> immediately. If the command has been processed successfully, client will rec…

Thank you

> This example is much the similar with the existing one except for the "code" and "msg".

This is true, which suggests that there is not much value in having the
additional example.  Thank you for showing me what it would look like,
though.

>  [Linlin] The "transform command" is mentioned in the previous text. So the status means "status in the response", no need to perform the <info> query. So how about changin like "The status in the…

I think that's an improvement, thanks.  (There might be further
improvements possible, but we probably don't need to look for them.)

>  [Linlin] This <poll>mechanism is supported in section 2.9.2.3 of RFC5730. So this is a easy and convinient way to inform the clients.

I'm saying that the choice for the server is not "do X or do Y", it's: "do
X, then either do Y or don't do Y".  The word "either" here implies that it
is sometimes acceptable to not do X (where X is the queuing of the service
message).

> I think "pan" is used to tell clients the following messages are "pending action notification". But for a particular element, this is just a "pending action" tag, not the notification message.

Ah, that makes sense -- thanks

-Benjamin

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 29 Oct 2018 09:55:22 +0800

Dear Benjamin,
Please see my feedbacks below. I've removed the clarified items.

Regards,
Linlin

Linlin Zhou
 
From: Benjamin Kaduk
Date: 2018-10-25 02:34
To: Linlin Zhou
CC: iesg; regext-chairs; Pieter Vandepitte; draft-ietf-regext-org; regext
Subject: Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)

It sounds like it is not worth making this change for this document, then.
Thanks for the background explanation!
[Linlin] On one hand, the duplicated elements are needed to address the server policy differences to make it easier for implementors. And on the other hand, it is consistent with the other EPP RFCs (RFC 5731 - 5733).

[Linlin] Thanks for your information. Learnt a lot.

[Linlin] Ok. Thank you.

 
 
[Linlin] Yes, thank you.

I'm saying that the choice for the server is not "do X or do Y", it's: "do
X, then either do Y or don't do Y".  The word "either" here implies that it
is sometimes acceptable to not do X (where X is the queuing of the service
message).
[Linlin] In my understanding, I think the text means do X or do Y. You can have two choices to inform the result by <poll> of EPP command or by out-of-band actions. The following <poll> response is an example using <poll> mechanism. Of course you can also send an email to to contact of the organization.
The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:)

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 29 Oct 2018 12:18:17 -0500

> The text is consistent with EPP RFCs. Maybe we can ask the author to confirm:)

Perhaps I am misreading, but I see this text in Section 4.2 that says that
the server MUST always send a service message to notify the client:

                                                                   Once
   the action has been completed, the client MUST be notified using a
   service message that the action has been completed and that the
   status of the object has changed.  Other notification methods MAY be
   used in addition to the required service message.

The text here in Section 4.3 says:

which would allow either the service message, or an out-of-band mechanism,
or both mechanisms used together.

My issue with the document is that the document is internally inconsistent
-- in Section 4.2 it says "always do X", but Section 4.3 contradicts that
by saying "you could do X, or you could not do X and do Y instead".  An
implementor has to pick whether to believe Section 4.2 or Section 4.3, and
we should not force them to make such a choice.

-Benjamin

---

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

Dear Benjamin,
Please see my feedbacks below.

Regards,
Linlin

Linlin Zhou

 
                                                                   Once

 

[Linlin] I can understand your concerns now. I think I had better propose a thread and ask the author or other EPP experts for confirmation. Once I get the feedback, I'll have a response. Thank you.

---

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

Dear Benjamin,
I re-read the two paragraphs again and again. And I think I have the thought in mind that "service message" may be the key words to make you confused. 
In section 4.2, "the client MUST be notified using a service message", this "service message" has a relatively broad meaning, that it means the in-band or out-or-band service message. And "MUST" means you must send the message whether online or offline to the client.
If the above understanding is proper, In section 4.3 "either by queuing a service message for retrieval via the <poll> command...", this "service message" is not specified for <poll> excusively. 
Of course, I'll try to confirm with other EPP experts in parallel.

Regards,
Linlin

Linlin Zhou
 
From: Linlin Zhou
Date: 2018-10-31 13:45
To: Benjamin Kaduk
CC: regext-chairs; Pieter Vandepitte; iesg; regext; draft-ietf-regext-org
Subject: Re: Re: [regext] Benjamin Kaduk's No Objection on draft-ietf-regext-org-11: (with COMMENT)
Dear Benjamin,
Please see my feedbacks below.

Regards,
Linlin

Linlin Zhou

 
                                                                   Once