Re: [regext] WGLC: draft-ietf-regext-org-02

[Antoin Verschuren <[e-mail]>]

Op 25 mei 2018, om 16:26 heeft Gould, James <jgould=[e-mail]> 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?
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?

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.

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?
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.
The risk is that this element may be wrongly interpreted when an organization has multiple <org:type> elements. (Verisign IS a Registrant, always ;-))


>  
>  
> James Gould
> Distinguished Engineer
> [e-mail]
>  
> 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" <[e-mail] on behalf of [e-mail]> 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: [phone]
>    
>     
>     
>     
>     
>     
>     Op 24 mei 2018, om 15:30 heeft Gould, James <jgould=[e-mail]> 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
>     > [e-mail]
>     >
>     > 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" <[e-mail] on behalf of [e-mail]> 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 <[e-mail]> 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
>     >> [e-mail]
>     >> https://www.ietf.org/mailman/listinfo/regext
>     >
>     >    _______________________________________________
>     >    regext mailing list
>     >    [e-mail]
>     >    https://www.ietf.org/mailman/listinfo/regext
>     >
>     >
>     > _______________________________________________
>     > regext mailing list
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/regext
>    
>     _______________________________________________
>     regext mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/regext
>    
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext