Dear Pierter,
Thanks for your comments. Please find my feedback below.
Regards,
Linlin Zhou
From: Pieter Vandepitte
Date: 2018-01-05 02:22
To: regext@ietf.org
Subject: Re: [regext] My review of draft-ietf-regext-org and
draft-ietf-regext-org-ext
Hi all,
In general, I share the same vision as Patrick. For me, the organization role
thing is still unclear to me. Especially its relation with the orgext:id links
from other entities to the organization.
I think this needs further explanation in the draft, if necessary with some
ascii art drawings to explain the model.
Maybe a bit late as I only very recently started following the list, but if I
would have to come up with an organization model:
Organisations are entities:
linked to 1 or multiple contacts. I would remove the org:postalInfo in favour
of a list of contacts, which is already in the current model. The org:postaInfo
is also a contact, so redundant and could be moved to the list of contacts.
Moreover, it is useful to describe the type of contact, which is not possible
to explicitly describe with the org:postalInfo element (is it the internal
contact, tech contact, public contact?)
having zero, one or multiple relations with other organizations. In my opinion
a role is a property of the relation an organization has with another
organization. E.g. X could be reseller of Y and at the same time registrar of Z
(yes, I would even create an object for the current registry Z, which allows to
exchange registry contact information with the registrar using org:info). So I
would remove the parentId and the role thing in favour of a new multi-occurence
"link" element of organization, having a role and an orgid attribute.
On the other hand, other entities like domains, contacts, hosts can also have 0
or more relations with an organization (which is basically what's in the other
draft)
[Linlin] 1. We take an organization as a entity that may have some contacts and
have its own postal information. Contacts have a "type" attribute. The type
values include "admin", "tech", "billing", "abuse", and "custom".
2. Until now, there seems no explicit need to create a "registry" organization.
I can undrerstand your thought, but it's hard to say whether this is a proper
solution.
3. Yes.
Maybe not related to the review of the draft (but related to the draft itself):
What is the purpose of this draft? It seems that it aims to build a model for
all organisations involved in the domain name registration business, which I
doubt there is a need for... But correct me if I'm wrong :-)
I think there is a need to link more contact information to a registration (and
to a greater extent any EPP object). Contact information like reseller, proxy
services, ...
So why not stick to that purpose and simply extend the contactAttrType for
contact role with values like "reseller", "proxy", ... and link a domain to a
contact using these new values?
[Linlin] The org drafts have been discussed for a long period of time. From the
very beggining, our requirements was to have a reseller extension for the
existing objects to show the whois information of some resellers. Then we found
that reseller may have its own contacts and hierarchy. So the reseller-ext and
a new reseller object drafts were submitted. WG had many voices, reuse
contacts, reseller object, generic object, etc.. Creating a generic
organization object was finally selected as the WG direction. So the authors
modified the whole reseller object to organization object. Making extensions
for EPP is a mechanism according to RFC3735. Revising the RFC5733 seems not to
be a very practical way.
Kind regards
Pieter
On 27 Dec 2017, at 07:02, Patrick Mevzek <p...@dotandco.com> wrote:
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
_______________________________________________
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
