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,
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.
[Linlin] Yes, it will be modified to "provisioning and management of
organization objects".
* 1. Introduction
Same remark about the plural.
[Linlin] Change to "such as registrars, resellers, DNS service operators, or
privacy proxyies".
"There are many domain entities" : maybe drop domain here?
Like: There are many entities
[Linlin] Ok.
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.
[Linlin] How aboult change the text to "These kind of entities have not been
formally defined as an object in EPP".
* 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.
[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
"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.
[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
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
[Linlin] Yes.
In fact the whole of 3.2 / 3.2.1 / 3.2.2 feels very complicated and not clear
to me.
[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
"terminated: The organization has been terminated MUST NOT be
linked."
=> and is missing before MUST NOT?
[Linlin] I think this should be "The organization which has been terminated
MUST NOT be linked."
* 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.
[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.
* 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.
[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.
" 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.
[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
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
[Linlin] Fine.
* 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.
[Linlin] Yes, same here. I'll change the xml schema in this part.
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.
[Linlin] o is needless here. I'll remove it.
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?
[Linlin] Change to "The entity object instance represents a third-party who
could help to register a domain without exposing the registrants' private
information."
* 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.
[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.
=================================================================================
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.
[Linlin] I think it is better to remove the second sentence.
* A organization mapping object defined in
=> An organization
[Linlin] Yes.
* 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.
[Linlin] Ok.
* 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.
[Linlin] Or change to "the server policy"?
* 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
[Linlin] To be more explicit, I'll add some text like "One or more <orgext:id>
element is allowed..." and remove minOccurs=0.
* 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?
[Lilin] Please find the feedback above.
* 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?
[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.
* 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.
[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?
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..."
[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.
* 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.
[Linlin] That would be great. Thank you again.
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.
[Linlin] Thanks for the generic comments. We will have some discussion and give
some more clear explanation in the document.
===================================================================
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.
[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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
