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.


Von: regext [mailto:regext-boun...@ietf.org] Im Auftrag von Antoin Verschuren
Gesendet: Freitag, 3. März 2017 18:08
An: Gould, James
Cc: Hollenbeck, Scott; regext@ietf.org
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.

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

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 
<jgo...@verisign.com<mailto:jgo...@verisign.com>> 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.

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?




James Gould
Distinguished Engineer

12061 Bluemont Way
Reston, VA 20190


From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on 
behalf of "Hollenbeck, Scott" 
Date: Friday, March 3, 2017 at 9:22 AM
To: "'i...@antoin.nl<mailto:i...@antoin.nl>'" 
Subject: [EXTERNAL] Re: [regext] Working group action required on 

From: regext [mailto:regext-boun...@ietf.org] On Behalf Of Antoin Verschuren
Sent: Friday, March 03, 2017 8:54 AM
To: regext <regext@ietf.org<mailto:regext@ietf.org>>
Subject: [EXTERNAL] Re: [regext] Working group action required on 

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 


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.


regext mailing list

Reply via email to