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

From: "[email-masked]" <[email-masked]>
Date: Tue, 2 Jan 2018 10:07:47 +0800

Hi Patrick,
I think the "role" of S: <orgext:id role="reseller">myreseller</orgext:id> is the same thing with "roletype" in S: <org:type roleStatus="ok">registrar</org:type>. If we change the name "role" to "roleType", is it better to help readers to understand?

Regards,

[email-masked]
 
From: Patrick Mevzek
Date: 2017-12-31 07:56
To: regext
Subject: Re: [regext] My review of draft-ietf-regext-org and draft-ietf-regext-org-ext
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:
> 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>
 
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.

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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 2 Jan 2018 14:45:43 +0000

Patrick,

The role applies to both the object (Organization) as well as the links (Domain to Organization).  In the data model, a generic Organization may have multiple roles (“registrar”, “reseller”, “privacyproxy”, etc.), each with an optional external identifier like the IANA ID for the registrar, and each with its own server defined status.  The Organization identifier is server defined and will most likely not match an external identifier like the IANA ID for the registrar, thus you need support for an optional identifier at the level of the Organization role.  The status defines whether new links can be made or whether there are existing links.  An Organization can provide multiple services (roles) and therefore the Organization has a status and each of the roles can have a status.  The link role is needed to easily identify was service the organization provides to the object.  The server defines the possible set of Organization roles via an out-of-band mechanism and the link roles to the organization can be server or client specified.   The links from the provisioning objects (e.g., Domain) and the Organization is a many-to-many relationship, which can be called Provider or Service Provider, that has a Role attribute that needs to be match up with one of the Roles defined for the Organization.  The Provider Role and the Organization Roles are linked to ensure that there are no orphaned links and to provide visibility into what links exist and what new links can be created.  The roles in both draft-ietf-regext-org and draft-ietf-regext-org-ext enable the definition of a generic Organization with an extensible set or service roles that are consistent.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 12/30/17, 6:56 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Linlin,

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

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 4 Jan 2018 18:22:03 +0000

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)

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?

Kind regards

Pieter

> On 27 Dec 2017, at 07:02, Patrick Mevzek <[email-masked]> 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
> ===================================================================
> 
> and then when you create/update a domain to add an organization you again specifcy a role.

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 05 Jan 2018 02:51:28 +0100

Hello Pieter,

On Thu, Jan 4, 2018, at 19:22, Pieter Vandepitte wrote:
> Maybe a bit late as I only very recently started following the list,

Welcome to the list then, fresh eyes and minds are always welcome.

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

Here is some history about these drafts, as a personal opinion and viewpoint,
before you go in the archives:

- the drafts were introduced to store reseller organization data in the registry,
as provisioned there by registrars
- there were then extensive discussion and quite a lot of pushback around
the question of why reseller data should be stored at the registry;
I myself voiced out the philosophical question to see why resellers were
suddenly more important than registrars, since the drafts would create
new reseller objects in the registry... which still does not have
registrars object!
- it was then collectively agreed for the drafts to be rephrased in order
to sustain coding for any kind of organisation, and not just only resellers;
this is where we stand right now
- there was a very recent question by James to see if they could be a little
extended to add some attributes needed specifically for registrars in order
to make transfers in gTLDs simpler/more secure.

I am still not convinced that there is a huge support from registrars
to store all of this data in the registry, and I have yet to see practical
use cases, hence my opinion not being very in favor of them, until at least
they make sense to me technically, hence my review. After which standard IETF
rules will prevail, so it is for sure good that more registries and registrars
voice their opinion, in whatever direction.

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

If you mean changing the current core EPP schemas, that would mean changing
the version, going from epp-1.0 to epp-1.1 or epp-2.0 and that would mean
a lot of changes in all registries and registrars.
And if you start going that road there are many other issues, small by
themselves but not negligible, that could be changed and enhanced in EPP.

So, in short, while technically the simplest/fastest case, this is unlikely to happen.

-- 
  Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Fri, 5 Jan 2018 10:47:37 +0800

Dear Pierter,

Thanks for your comments. Please find my feedback below.

Regards,

Linlin Zhou
 
From: Pieter Vandepitte
Date: 2018-01-05 02:22
To: [email-masked]

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.

[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

Hello authors,

* 1. Introduction

* 3.1

* 3.2

* 3.2.1

* 3.4

* 4.1

* 4.1.2
"A <org:status> element"

* 4.2.

* 4.2.1
A <org:status> element

* 4.2.5

     *  A <org:name> 

* 7.3

Other generic points:

-- 
 Patrick Mevzek