Subject: Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt

From: "Gould, James" <[email-masked]>
Date: Fri, 3 Mar 2017 15:12:16 +0000

I believe that “Option 1: A dedicated reseller object” is the best route to go.  I get the idea of creating a generic organization, but you need to consider the problem being considered and the difference of a registrar from a reseller.

1.      A registrar (direct customer) has a direct relationship with the registry and is provisioned outside of EPP or any B2B protocol.  A registrar organization would only support an info unless you enable a registrar to update their own record via EPP, which seems like a real stretch use case.

2.      A registrar is automatically attached to the provisioned objects (e.g., domain, host, and contact) in the registry based on the create and transfer commands.  There is need for tagging a provisioning object with a direct customer organization.

The problem that is being considered is making the resellers visible at the registry level to support tagging of provisioning objects for display in RDDS, for applying registrar controlled reseller policy (security, financial, etc.) at the registry level, and providing registry provided reports and visualizations split out by reseller.

Is there another problem that needs to be solved by elevating the reseller object up to the more generic organization?

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: regext <[email-masked]> on behalf of "Hollenbeck, Scott" <[email-masked]>
Date: Friday, March 3, 2017 at 9:22 AM
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt

From: regext [mailto:[email-masked]] On Behalf Of Antoin Verschuren
Sent: Friday, March 03, 2017 8:54 AM
To: regext <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt

No expressions of preference have been expressed for over a month now :-(
I think the authors deserve good guidance from the working group so they can progress their drafts, so let me be the first to express my motivation.
I hope we can discuss this in Chicago, so more opinions are certainly needed on the mailinglist!

[chair hat off, personal opinion]

I have a strong preference for option 2, a generic organization object, and a reseller mapping to such an organization object to identify resellers for a domain.

[snip]

Same here, though I don’t know if an organization object would need additional mappings or if it might be possible to just define roles for organizations. Bottom line is that I would prefer a generic organization object for all the reasons Antoin listed.

Scott

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 3 Mar 2017 18:07:50 +0100

Hi James,

I understand your distinction between registrar and reseller, and I agree.
Registrars are provisioned differently, and have a formal role to provisioning objects and contracts, just as registrants do.
I didn’t suggest to have registrars/registrants be transformed into generic organizations objects just yet if that was what you were thinking I meant.
It’s other future roles that I see similar to resellers why I would want a generic organizational object to be used for resellers.
If the name "generic organization” confuses you, we might also call it "additional registration liaisons” or whatever is appropriate, but it’s more than just resellers.

So in fact we would have 3 "objects" for entities/organizations:
1. Registrants (mandatory in any registration contract, even in a situation without registrars or resellers, yes, direct registrations still exist at some registries!)
2. Registrars (if present, usually authoritative for the provisioning data, and often also for billing information in the ICANN model at least)
3. All other organizations not formally defined by or mandatory in registration contracts.

The pragmatic problem being considered now is indeed making non contractual resellers visible, but I expect other organizations -not resellers- on the horizon with the same wish to be tagged to provisioning objects as well. They might need to be visible as well, or even have special permissions, and they might have multiple roles.
Roles I expect include dns-operators, auditors, expanded RDAP access credentials, abuse desks, law enforcement, privacy agents, data processors etc..
I wouldn’t want to define a new object every time I wanted to innovate service to customers. I just want to give the object an additional role in relation to a provisioning object, so they can use the new service belonging with that role.

- --
Antoin Verschuren

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

Op 3 mrt. 2017, om 16:12 heeft Gould, James <[email-masked]> het volgende geschreven:

> VerisignInc.com

---

From: Gavin Brown <[email-masked]>
Date: Mon, 6 Mar 2017 08:20:20 +0000

On 03/03/2017 17:07, Antoin Verschuren wrote:
[snip]
> The pragmatic problem being considered now is indeed making non
> contractual resellers visible, but I expect other organizations -not
> resellers- on the horizon with the same wish to be tagged to
> provisioning objects as well. They might need to be visible as well, or
> even have special permissions, and they might have multiple roles.
> Roles I expect include dns-operators, auditors, expanded RDAP access
> credentials, abuse desks, law enforcement, privacy agents, data
> processors etc..
> I wouldn’t want to define a new object every time I wanted to innovate
> service to customers. I just want to give the object an additional role
> in relation to a provisioning object, so they can use the new service
> belonging with that role.

I created a trivial EPP extension to allow additional contacts to be
associated with domains. It was designed with this purpose in mind:

https://gitlab.centralnic.com/centralnic/epp-auxcontact-extension/blob/master/draft-brown-auxcontact.txt

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 20 Mar 2017 07:36:56 +0000

Hello all,

I'm with Antoine - i think a generic "organization" object that can fulfill "roles" with regards to an "object" would be better than a object definition that's only useful for one single reseller use case. Even more complicated "chains" of resellers [rolling eyes] could be implemented by defining a role of  "is-reseller-of" and allowing that an organization object links to another organization using that role.

specifically (as someone said in Seoul), i'm puzzled by the fact that by adding a specific "reseller" object, we treat entities which typically have no contractual relation whatsoever with the registry as first-class objects, while we treat registrars (which are typically required to have such a relation) as an opaque non-existant object class.

Of course, the downside of defining a generic "organization" object is  that flexibility also creates complexity, and the option defined above would essentially allow creating almost infinitely complex networks of organizations. I'm not convinced i want that - however, my understanding for the requirement to drill down the chain of resellers several levels is limited anyways. But we're venturing too far into policy here.

best,
Alex

Von: regext [mailto:[email-masked]] Im Auftrag von Antoin Verschuren
Gesendet: Freitag, 3. März 2017 18:08
An: Gould, James
Cc: Hollenbeck, Scott; [email-masked]
Betreff: Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt [x_phishing]

Hi James,

I understand your distinction between registrar and reseller, and I agree.
Registrars are provisioned differently, and have a formal role to provisioning objects and contracts, just as registrants do.
I didn't suggest to have registrars/registrants be transformed into generic organizations objects just yet if that was what you were thinking I meant.
It's other future roles that I see similar to resellers why I would want a generic organizational object to be used for resellers.
If the name "generic organization" confuses you, we might also call it "additional registration liaisons" or whatever is appropriate, but it's more than just resellers.

The pragmatic problem being considered now is indeed making non contractual resellers visible, but I expect other organizations -not resellers- on the horizon with the same wish to be tagged to provisioning objects as well. They might need to be visible as well, or even have special permissions, and they might have multiple roles.
Roles I expect include dns-operators, auditors, expanded RDAP access credentials, abuse desks, law enforcement, privacy agents, data processors etc..
I wouldn't want to define a new object every time I wanted to innovate service to customers. I just want to give the object an additional role in relation to a provisioning object, so they can use the new service belonging with that role.

- --
Antoin Verschuren

Op 3 mrt. 2017, om 16:12 heeft Gould, James <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

I believe that "Option 1: A dedicated reseller object" is the best route to go.  I get the idea of creating a generic organization, but you need to consider the problem being considered and the difference of a registrar from a reseller.

-

JG

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

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

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 3, 2017 at 9:22 AM
To: "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>'" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt

From: regext [mailto:[email-masked]] On Behalf Of Antoin Verschuren
Sent: Friday, March 03, 2017 8:54 AM
To: regext <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt

[snip]

Same here, though I don't know if an organization object would need additional mappings or if it might be possible to just define roles for organizations. Bottom line is that I would prefer a generic organization object for all the reasons Antoin listed.

Scott