Subject: [regext] reseller drafts reviews

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 15 Aug 2016 15:54:20 +0800

Dear all,
The reseller drafts were suggested to have more reviews in last IETF meeting.  All of the issues raised on the mailing list have been solved and updated in the latest version. Any more review or comments on these two drafts are appreciated. 

Regarding the draft-ietf-regext-reseller,  we may have some choices of keep reseller information in my mind,
A. an ID and a name only
B. reuse contact object 
C. a independent reseller object, such as defined in draft-ietf-regext-reseller
The RDAP may only need a name displayed in response but there are still some other information we need such as the contact or parent registrar of a reseller. So option A may not seem as a good choice. Some registries have already use contact to keep reseller information, but after discussion we found that reseller and contact are not totaly the same. The reseller is a object that could have one or more contacts and it has hierarchical structure. So option B is also not take into consideration. Finally we decided to define a reseller object to full fill the existing and possible future requirements., which is a flexible way for any changes. Thoughts? 

Regards,

Linlin Zhou

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 15 Aug 2016 11:38:25 +0200

Hi Linlin,

I must admit I haven’t compared the proposed reseller structure to that of a registrar, but what happens when a reseller suddenly wants to become a registrar (or a registrar that will become a reseller under a larger registrar)? Use cases that I think happen regularly.
Is it just a matter of adding or removing a reseller:parentId?
I’d say option D to reuse the same fields for a reseller as a registrar, but with business logic that makes a lot of fields optional that would be mandatory for a registrar without a parentId. I mean, a reseller is an entity, just like a registrar but with different rights and obligations towards the registry, right? Would that work?
What is shown in RDAP is another matter, but at least we don’t need to reinvent and maintain a new structure, and we only need to agree on which fields are optional for which role, which may even be local policy.
Also thinking ahead of the possibility to administer 3th party dns-operators with limited rights agreed upon by the parent registrar, which might encounter the same question..
Just a thought.

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

Op 15 aug. 2016, om 09:54 heeft Linlin Zhou <[email-masked]> het volgende geschreven:

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

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 15 Aug 2016 18:48:13 +0800

Hi Antoin,
Thanks for your suggestion and I have some clarifications of your suggestion.
Actually in the reseller draft, we've thought the issue about registrar and reseller objects. The reseller has pretty much the same attributes that would be captured for a registrar if a registrar could be provisioned via EPP.  We really see the reseller object as more of an account object, where a registrar is an account without a parent. So in section 3.4, we've defined the parent identifier to show the hierarchy.

In the hierarchy discussion, we've drawn a  simple graph of reseller relations as below,
Registry------------------------ 
|                              |
|-Reseller----------------     |-Registrar
   |                     | 
   |-N-Tier Reseller     |-Reseller Customer
      |
      |-Reseller Customer
Registrar - Has direct contractual relationship with the registry and direct access to the registry without any sub-accounts
Reseller - Has direct contractual relationship with the registry and direct access to the registry with sub-accounts.  A reseller is really a Registrar with sub-accounts.
N-tier Reseller - Does not have a contractual relationship with the registry or direct access to the registry with sub-accounts.  
Reseller Customer - Does not have a contractual relationship with the registry or direct access to the registry without any sub-accounts.  
In our opinion, it may be easier for everyone to understand the scope of the object mapping, so we leave it as strictly a Reseller Object Mapping. As there is no object mapping for registrar, if we want to define a more general object including registrar and reseller, we may need a type attribute to differentiate them and may have some other adjustments which I am not thinking very clearly.

Regards,

Linlin Zhou
 
From: Antoin Verschuren
Date: 2016-08-15 17:38
To: Linlin Zhou
CC: regext
Subject: Re: [regext] reseller drafts reviews
Hi Linlin,

- -- 
Antoin Verschuren

Dear all,

Regards,

Linlin Zhou

---

From: "Gould, James" <[email-masked]>
Date: Mon, 15 Aug 2016 19:23:58 +0000

Hi,

As a co-author of these drafts and the one that pushed for the independent reseller object of “C”, I believe that “C” is the best choice with some explanation included below.

The driving reason for the creation of the reseller draft(s) is to enable the display of reseller information in RDDS at the registry level.  Let me be clear that I believe it is an anti-pattern (RDDS Copy Authoritative Data) to push authoritative data down to a party to display as if it were authoritative.  If the domain registry industry does support this anti-pattern, we may as well make it worth more than supporting RDDS.  Option “A” simply treats the reseller information as an attribute of the provisioning objects (domain, host, contact, etc.) while option “C” treats the reseller information as objects.  Items like ID uniqueness and reseller name changes is much more complex with the attribute model of “A”.  I really haven’t thought about option “B” much, but considering that a reseller is a separate object from a contact, I don’t believe reusing the contact mapping makes sense.  Option “C” supports RDDS and is extensible to support other reseller features like security, policy, financial, and reporting for registrars at the registry level.

In summary, option “C” models the real world and makes implementation of the RDDS Copy Authoritative Data anti-pattern have some value in supporting optional reseller channel features at the registry level in the future.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

VerisignInc.com<http://VerisignInc.com>

On Aug 15, 2016, at 3:54 AM, Linlin Zhou <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Regards,
________________________________
Linlin Zhou
_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 16 Aug 2016 12:00:26 +0800

Hi James,
Thanks for your explanation.

You just remind me of the first version of draft-ietf-regext-reseller-ext, we've put both ID and name in the extension. Then we found that there is no mechnism to keep the correctness of ID and name updates. So only the ID was kept in the latest version which is reffered to the reseller object identifier.
As for option B, I think we have indicated that reseller and contact are not totally the same. It is a object that could have contacts object and has hierarchical relations. So we do not want to mix them together.

Regards,

Linlin Zhou
 
From: Gould, James
Date: 2016-08-16 03:23
To: Linlin Zhou
CC: regext

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

VerisignInc.com 

On Aug 15, 2016, at 3:54 AM, Linlin Zhou <[email-masked]> wrote:

Dear all,

Regards,

Linlin Zhou

---

From: Rik Ribbers <[email-masked]>
Date: Mon, 22 Aug 2016 09:30:47 +0000

Linlin,

On 15 Aug 2016, at 09:54, Linlin Zhou <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

This seems to be the minimum-viable-product. However I can image you might want to add more fields, at least an email address for contacting the reseller…. so we need some sort of object.

B. reuse contact object

This would be my personal preferred object, however in our case the RFC5733 contact object did not have all the required fields…. so we need some sort of contact object or reseller object

Given the use-case this might seem interesting for the specific reseller use-case. However there are more use-cases on the horizon (e.g. 3rd party DNS operator). So are we going for a reseller specific solution this is the best (with a minimum set of required fields). However we might want to consider creating a more generic extension (like the entity in RDAP) which we can use for other objects to be labelled with.

The RDAP may only need a name displayed in response but there are still some other information we need such as the contact or parent registrar of a reseller.

If this is the ICANN policy (haven’t look for it yet though), we might want to consider adding the name as an optional field to the draft-ietf-regext-reseller-ext draft. So implementers have 2 choices. Implement only draft-ietf-regext-reseller-ext with the name field (so the domains can be simply labelled with a reseller name)  or implement the full EPP object with the draft-ietf-regext-reseller.

So option A may not seem as a good choice. Some registries have already use contact to keep reseller information, but after discussion we found that reseller and contact are not totaly the same. The reseller is a object that could have one or more contacts and it has hierarchical structure. So option B is also not take into consideration. Finally we decided to define a reseller object to full fill the existing and possible future requirements., which is a flexible way for any changes. Thoughts?

Conclusion:

Although at first it seems a little bit of overkill I came to the conclusion Option C is the best option, with the remarks that we need a minimum set of required fields. And optionally we could add the name back into the  draft-ietf-regext-reseller-ext if this makes it less effort to comply with ICANN policies for implementers.

Gr,
Rik

---

From: "Gould, James" <[email-masked]>
Date: Mon, 22 Aug 2016 14:02:38 +0000

Rik,

Your response made me think a little bit more around the problem that is being solved.  I see 2 problems that could be solved by formally defining the reseller and linking the reseller with objects in the registry:

  1.  Displaying the Reseller information in RDDS (RDAP).  Right now it is the reseller name that needs to be displayed, but what if more information is needed later like E-mail, URL, Address, Contacts, etc.?
  2.  Enable registrars to set security, policy, and reporting options for reseller’s at the registry level.  I can see many different use cases here that we’ve not yet fully discussed.

I don’t want to fall into the “RDDS Copy Authoritative Data” anti-pattern in solving problem #1 by having the registrars or even the resellers copying authoritative data down to the another party (registry) to display as if it were authoritative.  The registry does not need any additional information (address, voice, fax, email, url, contacts, disclose) for a reseller in solving problem #2, since the identifier, the name, and the relationship to the registrar and to the registry objects is important.

To solve both problems without falling into the “RDDS Copy Authoritative Data” anti-pattern, the following is needed:

  1.  Need to be capable of defining an object in the registry via the EPP Reseller Mapping with the minimal attributes required to solve problem #1 and #2.  Specifically the following information is needed:
     *   Identifier - Registry unique identifier that could be client specified or server generated.
     *   Name - Name of the Registrar that can be more easily referred to.
     *   GURID (Globally Unique Identifier) - This is similar to the GURID (IANA ID) for registrars or could be derived from it to create a globally unique identifier for resellers.
     *   RDAP URL - URL that can be referenced in the Registry RDAP to get the reseller information.  Any additional information associated with the Reseller can be retrieved by the authoritative source for this information and following the local privacy laws and regulations.  Although the reseller name is the only attribute that we’ve discussed thus far in RDAP, the technical solution should support additional information that can satisfy the local privacy laws and regulations effectively.
  2.  Need to be capable of linking registry objects to the reseller object via the EPP Reseller Extension.  The only attribute that is needed is the reseller identifier.  If more information is needed, the EPP Reseller Mapping can be used to get the GURID and the RDAP URL for subsequent lookups.  We don’t need or want any additional attributes in the links.  What would happen if the reseller name changed or any other relevant reseller information changed?  I don’t believe we would want to require an update to a large set of registry objects.

Thoughts?

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Aug 22, 2016, at 5:30 AM, Rik Ribbers <[email-masked]<mailto:[email-masked]>> wrote:

Linlin,

Dear all,

B. reuse contact object

Conclusion:

Gr,
Rik

---

From: Rik Ribbers <[email-masked]>
Date: Mon, 22 Aug 2016 15:11:13 +0000

Hi James,

On 22 Aug 2016, at 16:02, Gould, James <[email-masked]<mailto:[email-masked]>> wrote:

Rik,

Exactly the reason for creating an object (and going for option C in Linlin’s proposal). However if were are going to todo this for resellers specific we are going to have to create another EPP extension for every ”new” instance in the ecosystem as it evolves. I can image we do this for DNS-operators, but also for registrants (where the registry provides some additional services to registrants and the current contact mapping is not sufficient).

  1.  Enable registrars to set security, policy, and reporting options for reseller’s at the registry level.  I can see many different use cases here that we’ve not yet fully discussed.

Agreed this has not been discussed, and I do see some use cases. Although I doubt we would configure these options through EPP. I would provision this through some customer portal where the registrar can do this (either through a web interface or REST API).

If the GURID is indeed globally unique this is merely a technical identifier (primary key) and it is not even necessary in the EPP xml.

  1.

Interesting idea, we start mixing EPP and RDAP here…. For the EPP specification I would add an URL in the EPP XML and in the server policy I would state/specify that this must be an RDAP specific URL. What if there is a ccTLD with no RDAP support, one can simply add the website of the reseller. But I agree that these fields are the bare minimum.

  1.

+1, exactly what I had in mind.

Thoughts?

—

JG

<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

James Gould
Distinguished Engineer
[email-masked]<x-msg://55/[email-masked]>

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

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

Linlin,

Dear all,

B. reuse contact object

Conclusion:

Gr,
Rik

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 23 Aug 2016 14:32:11 +0800

Dear all,
Thanks Rik and James for your feedbacks.
I've listed the elements  and whether it is required in the reseller draft. Please send comments if you have other suggestions.
o <reseller:id> required

o <reseller:roid> required

o <reseller:state> required

o <reseller:parentId> optional

o One or two <reseller:postalInfo> elements

    *  <reseller:name> required

    * <reseller:addr>

        +  <reseller:street> One, two, or three optional

        + <reseller:city> required 

        + <reseller:sp> optional

        + <reseller:pc> optional

        + <reseller:cc> required

o <reseller:voice> optional

o <reseller:fax> optional

o <reseller:email> optional

o <reseller:url> required if it has

o Zero or more OPTIONAL <reseller:contact>

o <reseller:clID> required

o <reseller:crID> required

o <reseller:crDate> required

o <reseller:upID> required if it has

o <reseller:upDate> required if it has

o <reseller:disclose> optional

Regards,

Linlin Zhou
 
From: Rik Ribbers
Date: 2016-08-22 23:11
To: James Gould
CC: Linlin Zhou; regext

On 22 Aug 2016, at 16:02, Gould, James <[email-masked]> wrote:

Rik, 

Displaying the Reseller information in RDDS (RDAP).  Right now it is the reseller name that needs to be displayed, but what if more information is needed later like E-mail, URL, Address, Contacts, etc.?  

Enable registrars to set security, policy, and reporting options for reseller’s at the registry level.  I can see many different use cases here that we’ve not yet fully discussed.  

Need to be capable of defining an object in the registry via the EPP Reseller Mapping with the minimal attributes required to solve problem #1 and #2.  Specifically the following information is needed: 
Identifier - Registry unique identifier that could be client specified or server generated.  

Name - Name of the Registrar that can be more easily referred to.  
GURID (Globally Unique Identifier) - This is similar to the GURID (IANA ID) for registrars or could be derived from it to create a globally unique identifier for resellers.  
RDAP URL - URL that can be referenced in the Registry RDAP to get the reseller information.  Any additional information associated with the Reseller can be retrieved by the authoritative source for this information and following the local privacy laws and regulations.  Although the reseller name is the only attribute that we’ve discussed thus far in RDAP, the technical solution should support additional information that can satisfy the local privacy laws and regulations effectively. 

Need to be capable of linking registry objects to the reseller object via the EPP Reseller Extension.  The only attribute that is needed is the reseller identifier.  If more information is needed, the EPP Reseller Mapping can be used to get the GURID and the RDAP URL for subsequent lookups.  We don’t need or want any additional attributes in the links.  What would happen if the reseller name changed or any other relevant reseller information changed?  I don’t believe we would want to require an update to a large set of registry objects.  
+1, exactly what I had in mind. 

Thoughts? 

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

VerisignInc.com 

On Aug 22, 2016, at 5:30 AM, Rik Ribbers <[email-masked]> wrote:

Linlin,

On 15 Aug 2016, at 09:54, Linlin Zhou <[email-masked]> wrote:

Dear all,

B. reuse contact object 

Conclusion: 

Gr,
Rik

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 23 Aug 2016 13:20:57 +0200

Hi James,

I fully agree with your use cases. Thank you for clarifying them.

In addition this was actually my main question that has not been answered yet thinking ahead.
Looking from a registration/registry perspective I think that a registrant/registrar/reseller/dns-operator is only a role an entity has for a specific registration.
It is NOT a tag to the entity itself. You cannot say an entity IS a reseller, only that he performs a role as a reseller for a specific registration. It’s the relationship that is tagged, not the entity.

Outside the registry relationship, an entity is appointed or "tagged” as a reseller by a registrar, but that contract is not what a registry administers.

What happens if an entity is a registrant for one registration, a dns-operator for another one, a registrar for some others, and a reseller for yet another group?
Will he be in the registry 4 times in 4 different tables, or only once?
What if he is a reseller for multiple registrars?
What happens when he changes emailadress/phone number/address?
What happens when a reseller becomes a registrar for a new set of domains but remains reseller for the existing ones? Will his identifier and credentials change?

In my humble thought experiment, I think we should register a reseller the same as we do a registrar.
As long as he does not have a registrar role for any registration, but only a reseller role, far less data is required, but the entity will need to get an identifier and credentials that do not change once he will get an additional role.
So it’s business logic to determine how much data is required and displayed depending on the role the entity has in a specific registration. But a phone number is a phone number, an emailaddress is an emailaddress, and there is no difference in definition in emailaddress requirements of a reseller compared to that of a registrant or any other entity that needs to be administered. Once the local registry policy determines the emailaddress field is mandatory for an entity in a reseller role, the definition of an emailaddress is still the same..
Can this be done, especially looking at the way registrar and registrant entities are treated different now?

The question of authoritative data versus informational is an interesting one.
We need to know why the data needs to be in the registry in the first place.
If the data is to be used later for limited access rights to the database, like a dns-operator allowed to change an NS-set or a reseller allowed to change a registrant’s emailaddress, then it needs to be authoritative data from the registry perspective. Do we think that will never happen, or do we leave that decision to the business case of each individual registrar? I can imagine some registrars want to delegate some specific access rights and reporting, and others don’t. Should we provision for both, or only one use case?

Thoughts?

- --
Antoin Verschuren

---

From: "Gould, James" <[email-masked]>
Date: Tue, 23 Aug 2016 13:52:05 +0000

Antoin,

Good points.  My feedback is embedded below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Aug 23, 2016, at 7:20 AM, Antoin Verschuren <[email-masked]<mailto:[email-masked]>> wrote:

Op 22 aug. 2016, om 16:02 heeft Gould, James <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

Thoughts?

Hi James,

You are correct that in reality, an entity could play multiple roles, but it’s the roles that are relevant from a system perspective to apply security, policy, functional, and reporting options.  You could certainly have a conglomerate that serves multiple roles, but there are attributes that will be unique to each role.  I don’t believe that the registry should not have multiple copies of information not applicable in the security, policy, functional, and reporting options defined in problem #2, but that may be unavoidable.  I view the role taking priority over the entity in the domain registration data model, where there would be a role object that could reference a common entity, but it does not need to.

Let’s break down the data model based on who is authoritative for the information.  Let’s say that “Jim” plays all of these roles for most likely a completely different set of objects:

  *   “Jim” the Registrant - “Jim” the Registrant would register as a registrant with a registrar, who would be authoritative for the information.  “Jim” the Registrant could register many domains that get registered in the associated registries (e.g. jim.example1 in EXAMPLE1 registry, jim.example2 in EXAMPLE2 registry).  Do EXAMPLE1 and EXAMPLE2 registries really need “Jim” the Registrant information to fulfill their service?
  *   “Jim” the DNS Operator - I believe we would need to discuss the domain registration data model, what functions are available in the registry, and who is authoritative for what information for “Jim” the DNS Operator.
  *   “Jim” the Registrar - For ICANN accredited registrars, “Jim” the Registrar would be registered with ICANN, so ICANN would be authoritative for “Jim” the Registrar with the IANA ID as the globally unique identifier.  The registry would need a reference to the registrar to map up to the registry credentials, finances, and to link to registry objects.  For non-ICANN accredited registrars, then the Registry would be authoritative for “Jim” the Registrar unless there was some central non-ICANN accredited registrar authority.
  *   “Jim” the Reseller - “Jim” the Reseller has a contract with a registrar, who would be authoritative for the information.  “Jim” the Reseller’s registrar could create a link to “Jim” the Reseller in the registry that could be used to tag registry objects.  The only information that is needed in the registry is the bare minimum to enable the linkage to solve problem #1 and #2.

I would assume that he would be created as a separate entity for each registrar.  The relationship is between the reseller and the registrar, where there is no need for a central repository that all of the registrars link to.

He has to change the information in each place that is authoritative for the information.  “Jim” the Registrant could register domains with multiple registrars, but there is no need for the registrars to reference a single instance of “Jim” the Registrant.  Data is copied in this instance to multiple authoritative repositories, since there is no single authoritative repository for all entities and all entity roles.

No, they are viewed as different entities entirely.  Yes, it may be exactly the same organization, but they are viewed as different entities from a system perspective.

The main difference between a registrar and a reseller is the contractual and business relationship.  The registrars are setup in the registry with credentials, financial information, and access based on the contractual relationship.  A reseller has no direct relationship with the registry, so although it is an organization, it has a completely different set of features from a registrar.   It would be up to the registrar to register their resellers with the registry to be able to apply the appropriate security, policy, functional, and reporting options at the reseller level.

I don’t believe that we would want or need to attempt to merge all of the roles into a single entity to support items like a reseller morphing into a registrar.  The key is to keep the authoritative data with the authoritative source and link to those sources from non-authoritative parties.

Should the registry be the one to provide this information?  The registry may know of the relationships to support functionality, but having the registry get a copy of the data for display and making decisions as far as what to display runs into data privacy issues.

I believe that we should look at the data model for domain registration data and consider who is authoritative for each entity in the data model.  Pushing data down to the registry simply to support displaying it in RDDS is not the correct architecture that scales and that meets the data privacy issues.  In DNS we got away from the use of host files to use of a delegation resolution model.  RDAP supports a delegation resolution model, so why not leverage it instead of pushing data around?

The question for DNS operators as it is for any other domain-based service operator (web, e-mail, DNSSEC, parking, secondary market, etc.) is whether they should be formally defined in the domain registration data model and if so who would be authoritative for the information, what role does the registry play, and what privileges would they have.

Thoughts?

- --
Antoin Verschuren

---

From: Roger D Carney <[email-masked]>
Date: Tue, 30 Aug 2016 15:33:58 +0000

Good Morning,

I think I need to start at the beginning. Why are we wanting this solution? Is there a problem that we are trying to solve with this draft? Are registrars asking for this, it seems like a large burden for registrars?

As I have mentioned several times before, if this is a proposed solution for supplying the optional WHOIS display field Reseller Name from the registrar to the registry than I believe this solution is not appropriate, this is way too heavy handed and I don't see many registrars using this solution. Most of this information, registrars will not want to share and they will not want the management headache of maintaining all of this data at many different registries. Management of this would be a huge burden on registrars, trying to keep all the registries updated with this duplicated data every time some piece of reseller information changes.

If this internet-draft is trying to solve some other issue it would be good to understand that issue.

Assuming there is some other reason beyond using it as a solution for the optional WHOIS field of Reseller Name than I think we need to address some possible confusion on the definition of a Reseller. In the internet draft it seems fairly clear that a registrar is the customer of the registry and that some registrars have "agents" called resellers that may sell domain registrations on behalf of the registrar (section 1 of internet-draft). But the drawing that Linlin provided and the definition of Parent Identifier makes it sound like we want to call a Registrar with "agents", a Reseller, am I reading that correctly?

Thanks
Roger

From: regext [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Tuesday, August 23, 2016 8:52 AM
To: Antoin Verschuren <[email-masked]>
Cc: Rik Ribbers <[email-masked]>; Linlin Zhou <[email-masked]>; regext <[email-masked]>
Subject: Re: [regext] reseller drafts reviews

Antoin,

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

  1.  Displaying the Reseller information in RDDS (RDAP).  Right now it is the reseller name that needs to be displayed, but what if more information is needed later like E-mail, URL, Address, Contacts, etc.?
  2.  Enable registrars to set security, policy, and reporting options for reseller's at the registry level.  I can see many different use cases here that we've not yet fully discussed.

Thoughts?

Hi James,

In addition this was actually my main question that has not been answered yet thinking ahead.
Looking from a registration/registry perspective I think that a registrant/registrar/reseller/dns-operator is only a role an entity has for a specific registration.
It is NOT a tag to the entity itself. You cannot say an entity IS a reseller, only that he performs a role as a reseller for a specific registration. It's the relationship that is tagged, not the entity.

You are correct that in reality, an entity could play multiple roles, but it's the roles that are relevant from a system perspective to apply security, policy, functional, and reporting options.  You could certainly have a conglomerate that serves multiple roles, but there are attributes that will be unique to each role.  I don't believe that the registry should not have multiple copies of information not applicable in the security, policy, functional, and reporting options defined in problem #2, but that may be unavoidable.  I view the role taking priority over the entity in the domain registration data model, where there would be a role object that could reference a common entity, but it does not need to.

Outside the registry relationship, an entity is appointed or "tagged" as a reseller by a registrar, but that contract is not what a registry administers.

Let's break down the data model based on who is authoritative for the information.  Let's say that "Jim" plays all of these roles for most likely a completely different set of objects:

  *   "Jim" the Registrant - "Jim" the Registrant would register as a registrant with a registrar, who would be authoritative for the information.  "Jim" the Registrant could register many domains that get registered in the associated registries (e.g. jim.example1 in EXAMPLE1 registry, jim.example2 in EXAMPLE2 registry).  Do EXAMPLE1 and EXAMPLE2 registries really need "Jim" the Registrant information to fulfill their service?
  *   "Jim" the DNS Operator - I believe we would need to discuss the domain registration data model, what functions are available in the registry, and who is authoritative for what information for "Jim" the DNS Operator.
  *   "Jim" the Registrar - For ICANN accredited registrars, "Jim" the Registrar would be registered with ICANN, so ICANN would be authoritative for "Jim" the Registrar with the IANA ID as the globally unique identifier.  The registry would need a reference to the registrar to map up to the registry credentials, finances, and to link to registry objects.  For non-ICANN accredited registrars, then the Registry would be authoritative for "Jim" the Registrar unless there was some central non-ICANN accredited registrar authority.
  *   "Jim" the Reseller - "Jim" the Reseller has a contract with a registrar, who would be authoritative for the information.  "Jim" the Reseller's registrar could create a link to "Jim" the Reseller in the registry that could be used to tag registry objects.  The only information that is needed in the registry is the bare minimum to enable the linkage to solve problem #1 and #2.

He has to change the information in each place that is authoritative for the information.  "Jim" the Registrant could register domains with multiple registrars, but there is no need for the registrars to reference a single instance of "Jim" the Registrant.  Data is copied in this instance to multiple authoritative repositories, since there is no single authoritative repository for all entities and all entity roles.

I don't believe that we would want or need to attempt to merge all of the roles into a single entity to support items like a reseller morphing into a registrar.  The key is to keep the authoritative data with the authoritative source and link to those sources from non-authoritative parties.

So it's business logic to determine how much data is required and displayed depending on the role the entity has in a specific registration. But a phone number is a phone number, an emailaddress is an emailaddress, and there is no difference in definition in emailaddress requirements of a reseller compared to that of a registrant or any other entity that needs to be administered. Once the local registry policy determines the emailaddress field is mandatory for an entity in a reseller role, the definition of an emailaddress is still the same..
Can this be done, especially looking at the way registrar and registrant entities are treated different now?

If the data is to be used later for limited access rights to the database, like a dns-operator allowed to change an NS-set or a reseller allowed to change a registrant's emailaddress, then it needs to be authoritative data from the registry perspective. Do we think that will never happen, or do we leave that decision to the business case of each individual registrar? I can imagine some registrars want to delegate some specific access rights and reporting, and others don't. Should we provision for both, or only one use case?

Thoughts?

- --
Antoin Verschuren

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 31 Aug 2016 10:25:10 +0800

Dear Roger,
Thank you for your comments. Please see my feedback inline. 

Regards,

Linlin Zhou
 
From: Roger D Carney
Date: 2016-08-30 23:33
To: regext

    As I have mentioned several times before, if this is a proposed solution for supplying the optional WHOIS display field Reseller Name from the registrar to the registry than I believe this solution is not appropriate, this is way too heavy handed and I don’t see many registrars using this solution. Most of this information, registrars will not want to share and they will not want the management headache of maintaining all of this data at many different registries. Management of this would be a huge burden on registrars, trying to keep all the registries updated with this duplicated data every time some piece of reseller information changes.

Based on these questions, three options were posted on the mailing list. If you just want to display reseller name in WHOIS, treat the ID and name as attributes to the domain, host and contact objects, but you should consider the ID uniqueness and reseller name update issues. Although it seems a little overweight, you could have a minimal set of elements, such as name, URL, parentID, etc.. And you could also have oppotunity to extend other elemets to support  your own reseller requirements.

    Assuming there is some other reason beyond using it as a solution for the optional WHOIS field of Reseller Name than I think we need to address some possible confusion on the definition of a Reseller. In the internet draft it seems fairly clear that a registrar is the customer of the registry and that some registrars have “agents” called resellers that may sell domain registrations on behalf of the registrar (section 1 of internet-draft). But the drawing that Linlin provided and the definition of Parent Identifier makes it sound like we want to call a Registrar with “agents”, a Reseller, am I reading that correctly?
 
Actually, the graph I provided is from the view of system, the difference from the reseller and registrar is whether they have direct contractual realationship and accounts with a registry. In the real bussiness model, the graph should be,
 Registry------------------------ 
|                              |
|-Registrar----------------    |-Registrar
   |                      | 
   |-Reseller             |-Reseller
      |
      |-Reseller

Antoin, 

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

VerisignInc.com 
 
On Aug 23, 2016, at 7:20 AM, Antoin Verschuren <[email-masked]> wrote:

 
 
Thoughts? 

Hi James,

 

“Jim” the Registrant - “Jim” the Registrant would register as a registrant with a registrar, who would be authoritative for the information.  “Jim” the Registrant could register many domains that get registered in the associated registries (e.g. jim.example1 in EXAMPLE1 registry, jim.example2 in EXAMPLE2 registry).  Do EXAMPLE1 and EXAMPLE2 registries really need “Jim” the Registrant information to fulfill their service?  
“Jim” the DNS Operator - I believe we would need to discuss the domain registration data model, what functions are available in the registry, and who is authoritative for what information for “Jim” the DNS Operator.   
“Jim” the Registrar - For ICANN accredited registrars, “Jim” the Registrar would be registered with ICANN, so ICANN would be authoritative for “Jim” the Registrar with the IANA ID as the globally unique identifier.  The registry would need a reference to the registrar to map up to the registry credentials, finances, and to link to registry objects.  For non-ICANN accredited registrars, then the Registry would be authoritative for “Jim” the Registrar unless there was some central non-ICANN accredited registrar authority.  
“Jim” the Reseller - “Jim” the Reseller has a contract with a registrar, who would be authoritative for the information.  “Jim” the Reseller’s registrar could create a link to “Jim” the Reseller in the registry that could be used to tag registry objects.  The only information that is needed in the registry is the bare minimum to enable the linkage to solve problem #1 and #2.  

 

 

 

 
Thoughts?
 
- -- 
Antoin Verschuren