Oh, and when reviewing, I found another completely different issue, and that is with object ownership. I see a role can have an optional parentID, but what if my organization is reseller for more than one registrar within the same registry, and I want multiple reseller roles with a different parentID, which registrar is then entitled to change my organization data?
I can also see an issue of object hijacking. Suppose I’m a reseller for registrar A, but my organization is also dns-operator for domains at registrar B. I would think registrar B would not be allowed to change my organization object data that is maintained by registrar A. I could ask registrar A to add my dns-operator role type so registrar B could link my object to domains maintained by him, but registrar A could refuse that. Or should I have a different organization object at each registrar? I think that would not make things more orderly, and I could end up with a number of organization objects for my 1 organization in the same registry.. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 25 mei 2018, om 22:38 heeft Antoin Verschuren <i...@antoin.nl> het volgende geschreven: > Hi James, > > Thank you for explaining. I can understand your reasoning now. It’s the > client that authorizes the role an organization can have before it links a > domain in that role, except for the registrar role that is set by the server > based on local policy. > I would only make it more clear in the text that an organization can acquire > more than one role, and that the role type doesn’t say anything about an > organization itself other than it’s current abilities. > I suggest changing sections 3.2 and 3.2.1 (most important is the change of > would to could): > > 3.2. Organization Roles > > The organization roles are used to represent the relationship an > organization could have. Its corresponding element is <org:role>. > > 3.2.1. Role Type > > An organization could support a list of roles. An organization could have > multiple > roles with a different role type. See Section 7.3 for a list of role type > values. > Its corresponding element is <org:type>. > > (sorry for the layout mess up by my email client) > > Oh, and shouldn’t the registry in section 7.3 be called "Role Type Values > Registry" in stead of "Role Values Registry" ? > And if I can make another suggestion, I would certainly add a dns-operator as > an initial registry entry in section 7.3.2: > Value: dns-operator > > Description: The entity object instance represents a third-party > DNS operator that maintains the name servers and zone data on > behalf of a registrant.. > > Registrant Name: IESG > > Registrant Contact Information: i...@ietf.org > The justification being that I’ve seen that term used more in wishful > presentations than privacyproxy. > > - -- > Antoin Verschuren > > Tweevoren 6, 5672 SB Nuenen, NL > M: +31 6 37682392 > > > > > > > Op 25 mei 2018, om 20:27 heeft Gould, James > <jgould=40verisign....@dmarc.ietf.org> het volgende geschreven: > >> Antoin, >> >> My feedback is embedded below. >> >> — >> >> JG >> >> <image001.png> >> >> James Gould >> Distinguished Engineer >> jgo...@verisign.com >> >> 703-948-3271 >> 12061 Bluemont Way >> Reston, VA 20190 >> >> Verisign.com >> >> From: Antoin Verschuren <i...@antoin.nl> >> Date: Friday, May 25, 2018 at 12:19 PM >> To: James Gould <jgo...@verisign.com> >> Cc: Registration Protocols Extensions <regext@ietf.org> >> Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02 >> >> Op 25 mei 2018, om 16:26 heeft Gould, James >> <jgould=40verisign.....@dmarc.ietf.org> het volgende geschreven: >> >> >>> So my major question is: Can we still remove the <org:role> elements from >>> the organization object and only use the <orgext:id> in the domain objects >>> ? What would it break? Or could we at least have text that this role >>> element can never be set by a random EPP command for an organization but is >>> always set by the Registry? (so an info command would show it, but a create >>> or update could never set it?) Or is this local policy and do we need to >>> give guidance to registries as to why, when and how to set this in a BCP? >>> >>> Linking organizations to objects without a role loses meaning. Use of the >>> role is similar to a contact where a domain defines the contact type (role) >>> in the link to the contact. The difference here that a contact can be used >>> with any role (admin, tech, billing), but an organization may be authorized >>> by the server to act in various roles, where here is the need to control >>> what role linkages can be made to the organization. The possible set of >>> roles and who has the authority to manage the organization roles is up to >>> server policy. I believe the “registrar” role is server managed based on >>> the contracts, while the “reseller” and the “privacyproxy” roles would be >>> defined by the client. >> >> I think we mean the same thing here James, since I agree, But perhaps my >> question wasn’t clear. >> The role should be defined to the link between organization and domain >> object, not to the organization object itself. >> When I read section 4.2.1 of draft-ietf-regext-org: >> One or more <org:role> elements that contains the role type, role >> statuses and optional role id of the organization. >> for every organization object. >> >> Do you mean this element will automagicaly be populated with every possible >> <org:type> the registry supports for every new organization that is added in >> a role except that "registrar” can only be added by the Registry? >> >> The organization role type is not automagically populated, but is specified >> by the entity (client or server) that creates the organization. The >> “registrar” role can be set explicitly or implicitly by the Registry based >> on the registrar objects that already exist. If a registrar creates a >> reseller organization, the “reseller” role would be specified at the time of >> create. In section 4.2.1 “EPP <create> Command”, there must be one or more >> <org:role> elements provided by the client. If an organization is a >> “reseller” and also provides the “privacyproxy” service for the Registrar, >> then both roles can be set at the time of create. The point is that the >> organization roles define the capabilities of the organization and the >> ability to add new links using the the role statuses (e.g., >> clientLinkProhibited or serverLinkProhibited). >> >> Or does a client need to populate it with <org:type>"reseller”</org:type> >> when it creates this organization object for the first time in a reseller >> role for domain 1 , and then needs to add an additional >> <org:type>"dns-operator"</org:type> when the same organization object will >> be dns-operator for domain 2? >> And how will it be interpreted when an organization object has multiple >> <org:type>’s? Where is it used? >> >> A “reseller” link from domain 1 will only be authorized by the server if the >> referenced organization already has the “reseller” role and the organization >> “reseller” role does not have either the “clientLinkProhibited” or >> “serverLinkProhibited” status. The same holds for the “dns-operator” role, >> where the organization must already have the “dns-operator” role without a >> [client/server]LinkProhibited status to authorize Domain 2 to have the >> “dns-operator” link added. The organization can have many roles and each >> supported organization role can be associated with zero or more links to >> other objects (domain, host, contact, etc.). The linkage of an object to >> the organization does not define the capabilities of the organization. The >> organization’s capabilities are defined by their assigned roles. New links >> for the role can only be established when the organization supports the role >> and new links are not prohibited for the role. >> >> I would say that the <orgext:id role="reseller">myreseller</orgext:id> in >> the domain object in draft-ietf-regext-org-ext would define the role an >> organization performs for a domain object sufficiently. >> >> An organization is not a contact where the link defines it’s function. >> Organizations do have roles in the real-world (“reseller”, “dns-operator”, >> “privacyproxy”, etc.), which is what is modeled here. You don’t make an >> organization into a “reseller” based on the first link added to it and you >> don’t remove the fact that it’s a “reseller” by removing the last link. The >> roles define the capabilities and the ability to use that capability from >> other objects. >> >> So what’s the purpose of the <org:type> element in the organization object >> then? Only registry authorization to be allowed to perform a specific role? >> >> The <org:type> is an element of a <org:role>, where the organization can >> have many roles. The available set of roles along with who can manage the >> roles is based on registry policy, but I believe some of them are clear at >> this point (“registrar” is server managed, “reseller” is client managed, >> “privacyproxy” is client managed). >> >> I think that can be captured in a registry's EPP specification like a >> registry mapping document, but does not need to be limited in protocol >> specification. >> >> Yes, the available set of roles and the role policies (e.g., client managed, >> server managed) is well suited for an Organization Policy Extension to the >> Registry Mapping. I believe it’s a good exercise to define the options >> (MAYs and SHOULDs and the available options) of the extension that will be >> decided by server policy formally in a policy extension. >> >> The risk is that this element may be wrongly interpreted when an >> organization has multiple <org:type> elements. (Verisign IS a Registrant, >> always ;-)) >> >> The organization can have many roles like in the real-world, so I’m not sure >> how it can be wrongly interpreted. The existence of a link for a particular >> role is defined using the “linked” role status, which means that a role is >> used to define the capabilities of the organization that may or may not have >> existing object links using that role. The client can query an organization >> to get it’s available set of roles and then the client can link to the >> organization using one of the roles. >> >>> >>> >>> James Gould >>> Distinguished Engineer >>> jgo...@verisign.com >>> >>> 703-948-3271 >>> 12061 Bluemont Way >>> Reston, VA 20190 >>> >>> Verisign.com <http://verisigninc.com/> >>> >>> On 5/25/18, 9:45 AM, "regext on behalf of Antoin Verschuren" >>> <regext-boun...@ietf.org on behalf of i...@antoin.nl> wrote: >>> >>> Apologies for not having stepped into this discussion before. >>> Having to reread all the treads and all changes during WGLC now the >>> WGLC has ended I can understand Patrick’s concerns. >>> Since I was one of the many voices changing the reseller drafts into >>> the org drafts I will try to explain my concerns I had at the time. >>> I felt I was the only voice in the dessert at the time, but now that I >>> see all the changes, I will try to explain again. >>> This is my personal voice, so chair hat off. >>> >>> The reason I didn’t support the reseller drafts was twofold: >>> >>> 1. I saw the need for some registries to give organizations other than >>> the traditional Registrars and Registrants a role in the registration >>> process, but this was not limited to resellers. >>> The discussion started because resellers were complaining that their >>> name didn’t show up in the whois for specific registrations, and Registrars >>> were complaining that Registrants of those registrations would call them in >>> stead of their reseller. Registrants simply forgot who they had signed a >>> contract with, so they looked it up in whois. Registrars wanted to list >>> their reseller in whois. >>> Appart from resellers, I could see other roles in the future. Working >>> on Keyrelay, and the emerging dnsoperator-to-rrr draft, dns-operators would >>> be another organization registries might want to give special rights to, >>> for example to change NS records or roll DNSKEY material for domains they >>> were responsible for. >>> If we were to give every organization role it’s own extension, that >>> could lead to a forrest of organization types each with their own >>> specification. >>> >>> 2. Coming from way back when we still had only admin-c, tech-c and >>> billing-c contacts (which btw, were often one and the same person, so 1 >>> NIC-handle) and no registrars, I rejected the business marketing thought >>> that an organization IS, and can only be a one of a choice between >>> Registry, Registrar, Registrant, Reseller or DNS-operator. An organization >>> can play a role as Registrar for one registration, but could play the role >>> of a DNS-operator only for another registration. It’s NOT: Once tagged a >>> reseller, always a reseller. For our purpose of registering registrations, >>> the contractual business relationship organizations have between each other >>> is of no matter. We only need to know the role an organization plays for a >>> specific registration. >>> Trick question for bonus points: who IS a Registry, Registrar and >>> Registrant for verisign.nl ? >>> >>> So we can never "tag” an organization as: This one IS a Registrar, this >>> one IS always a reseller. >>> It might be so that an organization can only perform a role as a >>> Registrar for specific registries once he is accredited by ICANN or has >>> signed a registrar agreement with a non gTLD, but that bookkeeping should >>> not be part of EPP. EPP is a provisioning protocol that only administers >>> registrations of Internet identifiers, it is not a CRM system. >>> >>> So I share Patricks concern during WGLC regarding: >>> --- >>> > I guess it's the fact >>> > that roles are defined as properties of the organization and at the >>> same >>> > time as properties of the link? >>> >>> Yes, that is one troublesome point I raised months ago. >>> — >>> >>> Having said that, I can also understand James reasoning that if any >>> organization could perform any role, why not simplify even more and also >>> administrate Registrars and Registrants as organizations. >>> But this leads to the basic bookkeeping challenge of when to give an >>> organization rights to register with the registry system or perform other >>> tasks. >>> I assume this is the reason why one would like to tag an organization >>> as "Registrar” for that specific registry only, because that Registry wants >>> to know if that organization has signed a registrar agreement to give >>> registration rights in the registry system. And tag an organization as a >>> reseller to give him f.e. rights to perform info commands for domains. >>> >>> So while I understand the tagging of an organization for this purpose, >>> I believe it should not be set through EPP. It’s only the Registry itself >>> that can set this tag internally in the registry system after all the CRM >>> and contract thingies have been verified. >>> >>> So my major question is: Can we still remove the <org:role> elements >>> from the organization object and only use the <orgext:id> in the domain >>> objects ? What would it break? Or could we at least have text that this >>> role element can never be set by a random EPP command for an organization >>> but is always set by the Registry? (so an info command would show it, but a >>> create or update could never set it?) Or is this local policy and do we >>> need to give guidance to registries as to why, when and how to set this in >>> a BCP? >>> >>> - -- >>> Antoin Verschuren >>> >>> Tweevoren 6, 5672 SB Nuenen, NL >>> M: +31 6 37682392 >>> >>> >>> >>> >>> >>> >>> Op 24 mei 2018, om 15:30 heeft Gould, James >>> <jgould=40verisign....@dmarc.ietf.org> het volgende geschreven: >>> >>> > Pieter, >>> > >>> > It is interesting that when the drafts came out for resellers there >>> was a lot of discussion on the list and at the working group meetings, but >>> once there was agreement to create the more generic organization drafts, >>> there was very little discussion. It was pointed out that the organization >>> drafts would be more complex to address a broader set of use cases, but >>> that was the direction received by the working group. The use case of >>> providing registrar information via EPP was brought up as a reason to >>> define the more generic organization drafts, which I view as the most >>> straight forward and least controversial use case. >>> > >>> > The question around the roles was raised on the list and discussed on >>> the list, so I'm not sure whether there are any further questions or issues >>> that need to be addressed. If there are I would like to know what the >>> issues are. >>> > >>> > Thanks, >>> > >>> > — >>> > >>> > JG >>> > >>> > >>> > >>> > James Gould >>> > Distinguished Engineer >>> > jgo...@verisign.com >>> > >>> > 703-948-3271 >>> > 12061 Bluemont Way >>> > Reston, VA 20190 >>> > >>> > Verisign.com <http://verisigninc.com/> >>> > >>> > On 5/24/18, 6:38 AM, "regext on behalf of Pieter Vandepitte" >>> <regext-boun...@ietf.org on behalf of pieter.vandepi...@dnsbelgium.be> >>> wrote: >>> > >>> > Hi Patrick, >>> > >>> > I respect your opinion and my gut feeling says it won't be used >>> for anything else than resellers. But I might be wrong (and history tells >>> me the odds are agains me :-)). I also respect the opinion of others and >>> it's not up to me to assess in depth the needs of other registries, I can >>> only challenge and trust other participants to act truthful. More important >>> to me, the model seems correct and logical, with the others' point of view >>> and needs in the back of my head. >>> > The only thing that bothers me in general (not only for this >>> extension) is the low participation in discussion making it difficult to >>> develop a specification that fits all needs. >>> > >>> > I do not agree with you regarding not moving forward. A lot of >>> registries -including the one I work for- are reluctant to implement >>> anything other than RFCs (how many extensions with status Informational in >>> the EPP extensions registry are implemented by more than 1 registry?) >>> > Registrars are not happy with ad hoc extensions and I share their >>> concerns. Moving forward is the necessary step to be able to converge to a >>> single implementation for modelling resellers (and to enable >>> interoperability) >>> > >>> > It is certainly not my intention to try to convince you to approve >>> the draft. I will continue my write-up but I will write down your concerns >>> and it's up to others to decide whether the Draft can become a Proposed >>> Standard >>> > >>> > Kind regards >>> > >>> > Pieter >>> > >>> > >>> >> On 24 May 2018, at 07:44, Patrick Mevzek <p...@dotandco.com> wrote: >>> >> >>> >> On Wed, May 23, 2018, at 13:36, Pieter Vandepitte wrote: >>> >>> @Patrick, did you have time in mean time to catch up? How would you >>> like >>> >>> the draft to be changed in order to support it? >>> >> >>> >> I unfortunately think that I am not convinced by the use case, and I >>> believe that the document could be an I-D referenced on the IANA EPP >>> Extensions registry without the need to become an RFC. Which other registry >>> wish to use it on their systems? And if there is, then for other things >>> than resellers? >>> >> >>> >> That does not change anything on the WG consensus on the documents, >>> which should proceed on their own pace. >>> >> >>> >>> I guess it's the fact >>> >>> that roles are defined as properties of the organization and at the >>> same >>> >>> time as properties of the link? >>> >> >>> >> Yes, that is one troublesome point I raised months ago. >>> >> >>> >> -- >>> >> Patrick Mevzek >>> >> >>> >> _______________________________________________ >>> >> 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 >>> > >>> > >>> > _______________________________________________ >>> > 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 >>> >>> _______________________________________________ >>> 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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
