Scott,
To turn the reseller object into a general organization, it would entail doing the following: 1. Change the name as you noted from Reseller to Organization for the object (draft-ietf-regext-reseller to draft-ietf-regext-org or draft-ietf-regext-genorg) and to the command response extension (draft-ietf-regext-reseller-ext to draft-ietf-regext-org-ext or draft-ietf-regext-gen). I would prefer just referring it at as Organization or org. 2. Add the concept of role or type to the object (draft-ietf-regext-org). I prefer the term role over type, since type is more useful when it’s a 1-to-1 relationship. a. One could argue that there is no need to tag the roles on the object, like is the case for contacts. I believe this is what differentiates an Organization from a Contact. The roles define the Organization’s purposes as opposed to deriving the purposes from the relationships to it. 3. Add the concept of role or type to the command response extension (draft-ietf-regext-org-ext ) to enable specifying the role relationship to the Organization. 4. Finally, there should be a registered set of roles, so there is not a confusing set of roles used in the wild (e.g., reseller, resellerCustomer, resellerCust, nTierReseller, dnsProvider, dnsOperator, dnsOp, privacy, privacyProxy). — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 4/3/17, 10:21 AM, "regext on behalf of Hollenbeck, Scott" <regext-boun...@ietf.org on behalf of shollenb...@verisign.com> wrote: I've been giving some thought to the possibility of writing up a proposal for a generic organization object that can be compared to the proposal we have for a reseller object since the topic came up at last week's meeting. After looking things over I concluded that a generic organization object would look an awful lot like what's already written for the reseller object, so I'd like to suggest an alternative that doesn't require a lot of text cloning. Step 1: If the object described in draft-ietf-regext-reseller were changed from "reseller" to "genOrg" (or something similar), we would have an object that could be used to describe a generic organization. We might need to add or modify a field or two or more, but I think what's there is close. Step 2: If the extension described in draft-ietf-regext-reseller-ext were modified to note different types of extended organization relationships, we could have support for resellers, DNS service providers, hosting providers, and/or whatever other organization relationships people see a need for. An extended <info> response, for example, could look like this: S:<extension> S: <genOrgExt:infData xmlns:genOrgExt="urn:ietf:params:xml:ns:genOrgExt-1.0"> S: <genOrgExt:id type="reseller">myreseller</genOrgExt:id> S: <genOrgExt:id type="dnsProvider">myDNSProvider</genOrgExt:id> S: </genOrgExt:infData> S:</extension> We could add an IANA registry for organization identifier types. Is something like this worth considering? It looks pretty simple to me. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
