Subject: [regext] My review of draft-ietf-regext-org and draft-ietf-regext-org-ext

From: Patrick Mevzek <[email-masked]>
Date: Wed, 27 Dec 2017 07:02:26 +0100

Hello authors,

Please find my review of your two drafts.
I do not think they are ready for WG last call yet.

=================================================================================
draft-ietf-regext-org
=================================================================================

* Abstract: "provisioning and management of organization object"
I would says objects in plural is more logical.

* 1. Introduction
Same remark about the plural.

"There are many domain entities" : maybe drop domain here?
Like: There are many entities 

Also I have mixed feelings on "These kind of entities have not been formally
   defined in EPP"
This is not true for registrar, for example, it is clearly defined in RFC3375.

So you will need to rephrase your paragraph.

* 3) I do not understand "can be viewed and modified by the sponsoring client or the server."
Why do you specify "or the server." ?
The fact that the registry can view the data seem quite obvious but what
are you trying to infer by speaking about server modifications?
I think it would be far simpler to just remove "or the server."

"This section describes each attribute type in detail."
You can remove "type" I think.

* 3.1
"Organization identifiers are character strings with a specific
   minimum length, a specified maximum length, and a specified format.
   Organization identifiers use the "clIDType" client identifier syntax
   described in [RFC5730]."

The clIDType in RFC5730 specifies a minimum and maximum length but no format,
just that it is a token. So the sentence is kind of wrong.

* 3.2
This does not seem clear enough to me.
I have to wait for further examples down below to better understand this
But did not found enough examples or further explanations,
so all of this is confusing to me.

* 3.2.1
"Its corresponding element is <org:type> with an
   "roleStatus" attribute."
=> a instead of an I think

In fact the whole of 3.2 / 3.2.1 / 3.2.2 feels very complicated and not clear to me.

* 3.3 what does this section has to do with the rest of the document?

* 3.4
"terminated: The organization has been terminated MUST NOT be
      linked."
=> and is missing before MUST NOT?

* 3.6 "the parent identifier is
   not defined for the top level reseller, namely the registrar of the
   registry."
I am not absolutely sure that registrars would be happy to be depicted as 
just resellers of the registry, and also I am not sure what this sentence
adds to the protocol.

* also in section 3 somewhere you should speak about timestamps
since you have crDate, etc.
See §2.4.  Dates and Times for example in RFC5731.

* 4.1
"EPP provides two commands" 
It is instead 3 if you add the <transfer> case, so you should rephrase that
paragraph.

* 4.1.2
"A <org:status> element"
Only one status available here?
If multiple allowed, you have to fix this sentence and the associated XML schema.

"   Example <info> response for "Example Registrar Inc." registrar object
   with registrar identifier "1362":"
Maybe instead to be more inline with the rest of the document:
   Example <info> response for "Example Registrar Inc." organization object
   with organization identifier "1362":

And then below the example has:
<org:id>registrar1362</org:id>
So the text above should probably more be:
with organization identifier "registrar1362"

Same kind of changes for the later examples which follow a similar introducing
sentence.

* 4.2.
Why don't you count the renew command as one transform command?
(even if you speak about it further down)

* 4.2.1
 A <org:status> element
Same remark/question as above in 4.1.2

"A <org:crDate> element that contains the date and time of
      organization-object creation."
=> organization object instead of organization-object

* 4.2.5
I have the same issue as above related to your handling of status.
You again seem to imply it can appear once, and hence be handled through <chg>
However rereading 3.4 it seems totally legit for me for example to have
clientLinkProhibited
clientUpdateProhibited
clientDeleteProhibited
if the sponsoring registrar so wish.

So you either need to specify somewhere that only one status value can exist
at any time (and then you will have multiple other problems) or you will
need to update all your documents as reviewed earlier to allow multiple
status values at the same time, and then also change it to be handled through
add/rem and not with chg.

You also have a "bullet" problem as your document renders as:
 o

      *  A <org:name> 

So, something missing after the o, or an indentation problem.

Your example is not clear, with:
<org:status>ok</org:status>
since in 3.4 you say that the ok value is put or removed by the server
(implying it is not handled by the client).

* 7.3
"The entity object instance represents a third-party who
      could help to register a domain without exposing their private
      information."

This is not clear, what does "their" reference in this sentence?

* 8 Implementation status

Net::DRI implements a previous version of your drafts. If interested I could try to update it so that you can add it there. Please let me know what you think and if you do reference it please use the software name instead of my own personal name.

=================================================================================
draft-ietf-regext-org-ext
=================================================================================

* The abstract seem wrong: "this
   extended mapping is applied to provide additional features required
   for the provisioning of organizations."
This document deals with "linking" specific organization IDs to other objects,
not provisioning it. It seems a sentence copied from the other document but
it has no sense here. On the contrary you should more specifically link to the
other document to clearly explain how they interoperate.

* A organization mapping object defined in
=> An organization

* 4.1.2 "However, additional elements are
   defined for the <info> response."
=> you should specify if this is for domain, host or contact since just in the previous
sentence you took care to specify that you do not add anything to the domain contact and host
info commands.

* 4.1.2 "if the object has data associated with this
   extension and based on its service policy."
Do you mean *registry* service policy? The its seem to refer to the object.

* 4.1.2 "A <orgext:id> element that contains"
This is not consistent where the example below where you have 2 elements.
So the text should say something like "One or more <orgext:id> element..."
The related schema is also wrong since you have minOccurs=0
It is doubly inconsistent since having no id at all makes an empty extension
so no use; and on the contrary you want to have more than one.
So please make text, example and schema consistent from each other.

Are you sure in fact that the schema is correct? Does the role attribute
really apply to the id element, I am not sure this is what I read from the schema,
there it seems to apply to the outermost enclosing element.
You should have a look in RFC5730 for example on how domain:contact are defined
in a domain:create or domain:info

* 4.2.1 You should specify if you speak about domain, contact or host objects.
You have the same problem I think than in 4.1.2. The schema (maybe wrong, see same
remark above) seems to allow only one id element, is this really what you want?

* 4.2.4 I was not sure to understand what you say in:
"the handling of the assigned organization is dependent
   on the organization roles and server policy." can you elaborate?
Also you speak about "an assigned organization" so you do not consider more than one?

* 4.2.5 I am not sure to understand the difference between add+rem and chg, except that
it seems you allow only one id per type, hence the chg case. If that is so,
please explicitely say so, even before in the document. If not, please explain the difference
between doing an add or rem and doing a chg.
In light of what I reiterated above, please specify what is happening if there
are already more than one id attached to the object, and even more if there are more
than one per role.

The schema specification for update has the same problem as above regarding
the cardinality of the id element and the position of the role attribute. Please
double check that. Explain what minOccurs=0 could do as this could result into
an empty <add> or empty <rem> or empty <chg>

* 6 Internationalization Considerations

I do not understand this section. How does this document add anything related
to this from what is already in core EPP? You seem to have copied what is there
which does not add value.

This sentence has a problem also:
"As an extension of the EPP domain name mapping, the elements, element
   content described in this document MUST inherit..."

* 8 Implementation status

Net::DRI implements a previous version of your drafts. If interested I could try to update it so that you can add it there. Please let me know what you think and if you do reference it please use the software name instead of my own personal name.

Other generic points:
- please specify what is happening if the client uses a value for the role attribute that is not supported by server policy, how should it react?
- same if client uses an organization ID during create/update that does not exist at registry side
- in the schema the role value is just an XML token whereas in your text you refer to section 7.3 of the other document for the list of values. I expect the XML schema to also reflect that. You should probably define it in the schema of the "org" element and have the XML schema in the "orgext" document refer to the one in the "org" document. Like EPP has "epp" and "eppcom" schema, and "eppcom" is refered from various domain/host/contact XML schema.
- "Organization Extension", and associated "orgext" short name do not seem specific enough
for me. Maybe you could try to find something more precise? In fact same problem for the other document.
- maybe explain if organization ID are global inside the registry or per registrar; so what happens if registrar X creates an orgnization and registrar Y uses it for domains it manages.

===================================================================
comments related to both
===================================================================

I am more than a little fuzy about your "role" uses.
When you create an organization you specify a role,
and then when you create/update a domain to add an organization you again specifcy a role.
Are they the same or different? Why do they need to be repeated?

This whole idea of "role" will need to be seriously improved in both documents.

-- 
  Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 28 Dec 2017 17:58:32 +0800

Dear Patrick,
Thanks for your careful review and comments. Please find my feedbacks below. Some of the text will be updated in the next version.

Regards,

Linlin Zhou
 
From: Patrick Mevzek
Date: 2017-12-27 14:02
To: regext
Subject: [regext] My review of draft-ietf-regext-org and draft-ietf-regext-org-ext
Hello authors,

 

[Linlin] Yes, it will be modified to "provisioning and management of organization objects".

* 1. Introduction

[Linlin] Change to "such as registrars, resellers, DNS service operators, or privacy proxyies".

[Linlin] Ok.

[Linlin] How aboult change the text to "These kind of entities have not been formally defined as an object in EPP".

 
[Linlin]  This section tries to be consistent with RFC5733. You can find "An EPP contact object has attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail." in section 2 of RFC5733.

* 3.1

[Linlin] This part of words also tries to be consistent with RFC5731, RFC5732 and RFC5733. I guess that token is a formatted string that removes the spaces, tabs , line breaks.
 
* 3.2

* 3.2.1

[Linlin] Yes. 

[Linlin] I'll try to add an example like this,

S: <org:role> 
S: <org:type roleStatus="ok">registrar</org:type> 
S: <org:roleid>1362</org:roleid> 
S: </org:role>

* 3.3 what does this section has to do with the rest of the document?
[Linlin] We intend to explain that an organization would have one or more contacts. So this section specifies the contact identifier formats.

* 3.4

[Linlin]  I think this should be "The organization which has been terminated MUST NOT be linked."

[Linlin] We are trying to say that registrar, N-tier reseller and reseller customer are three types of organization in reseller business model. Only N-tier reseller and reseller cutomer could have a parent ID.
 
[Linlin] Ok.
 
* 4.1
"EPP provides two commands" 
It is instead 3 if you add the <transfer> case, so you should rephrase that
paragraph.
[Linlin] I'll reconsider the text and udpate in the next version.
 
* 4.1.2
"A <org:status> element"
Only one status available here?
If multiple allowed, you have to fix this sentence and the associated XML schema.
[Linlin] I think multiple statuses are allowed. A maxOccurs attribute will be added in the "status" element.

[Linlin] Yes, that's more clear to readers.
 
* 4.2.
Why don't you count the renew command as one transform command?
(even if you speak about it further down)
[Linlin] In section 4.2.3, "Renewal semantics do not apply to organization objects, so there is no mapping defined for the EPP <renew> command.". So there are no <transfer> or <renew> commands included in the document.
 
* 4.2.1
A <org:status> element

[Linlin] Fine. 
 
* 4.2.5

[Linlin] Yes, same here. I'll change the xml schema in this part.

      *  A <org:name> 

[Linlin] o is needless here. I'll remove it.

* 7.3

[Linlin] Change to "The entity object instance represents a third-party who could help to register a domain without exposing the registrants' private information."

[Linlin] Thank you. That would be so good if you can update your implementation. I'll update the information in the document. So please let me know if you have completed.

[Linlin] I think it is better to remove the second sentence.

[Linlin] Yes.

[Linlin] Ok.

[Linlin] Or change to "the server policy"?

[Linlin] To be more explicit, I'll add some text like "One or more <orgext:id> element is allowed..." and remove minOccurs=0.

[Lilin] Please find the feedback above.

[Linlin] In the previous reseller draft, we wrote like this "but after a successful transfer of an object with an assigned reseller, the server SHOULD clear the assigned reseller value." We consider that after a transfer, the object may not be linkde with this reseller. So we change the text a little in org draft. Whether to link with a organization, you should take org role and server policy into consideration. 
 
[Linlin] From my understanding, you can have multiple ids with different roles and it is more reansonable to have one id per role. What do you think?

 

[Linlin] It should be "the elements and element content".  This section is copied from org draft, we will discuss if it is possible to remove it.

[Linlin] That would be great. Thank you again.
 
Other generic points:
[Linlin] Thanks for the generic comments. We will have some discussion and give some more clear explanation in the document.

 
 
 [Linlin] Actually the two role have the same value referring to section 7.3 in draft-ietf-regext-org. I think we need add some words in the org-ext draft to explain that you should go to org draft to find the role values. 
S: <org:role> 
S: <org:type roleStatus="ok">registrar</org:type> 
S: <org:roleid>1362</org:roleid> 
S: </org:role>

 S: <orgext:id role="reseller">myreseller</orgext:id>
-- 
  Patrick Mevzek
 
_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 31 Dec 2017 00:56:15 +0100

Hello Linlin,

I will wait on next versions of your draft to see how they got changed, but I still
have one major point:

On Thu, Dec 28, 2017, at 10:58, Linlin Zhou wrote:
>  [Linlin] Actually the two role have the same value referring to section 
> 7.3 in draft-ietf-regext-org. I think we need add some words in the org-
> ext draft to explain that you should go to org draft to find the role 
> values. 
> S: <org:role> 

Even with your reply I think I still do not understand enough what you are trying
to do with the whole role/roleid/rolestatus things and the fact that it is both
an attribute of the organization object and an attribute of the link between the organization object and the domain object.
If it is the same value, then one of them is redundant and should be removed I think.

I hope to understand this more in your later versions. Do not hesitate to add more
text and examples.

-- 
  Patrick Mevzek