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: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 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 <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? - JG <image001.png> James Gould Distinguished Engineer jgo...@verisign.com<x-msg://6/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org<mailto:regext-boun...@ietf.org>> on behalf of "Hollenbeck, Scott" <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> Date: Friday, March 3, 2017 at 9:22 AM To: "'i...@antoin.nl<mailto:i...@antoin.nl>'" <i...@antoin.nl<mailto:i...@antoin.nl>>, "'regext@ietf.org<mailto:regext@ietf.org>'" <regext@ietf.org<mailto:regext@ietf.org>> Subject: [EXTERNAL] Re: [regext] Working group action required on draft-ietf-regext-reseller-ext-01.txt 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 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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
