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

["Linlin Zhou" <[e-mail]>]

Dear Antion,
I think in the current model, a reseller may be a reseller of multiple registrars, but they would have a unique identifier per registrar. So they would managed independently by the registrar.
 
Regards,
Linlin


[e-mail]
 
From: Antoin Verschuren
Date: 2018-05-26 05:39
To: Registration Protocols Extensions
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
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: [phone]






Op 25 mei 2018, om 22:38 heeft Antoin Verschuren <[e-mail]> 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: [e-mail]

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: [phone]






Op 25 mei 2018, om 20:27 heeft Gould, James <jgould=[e-mail]> het volgende geschreven:

Antoin,
 
My feedback is embedded below.
  
—
 
JG

<image001.png>

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com
 
From: Antoin Verschuren <[e-mail]>
Date: Friday, May 25, 2018 at 12:19 PM
To: James Gould <[e-mail]>
Cc: Registration Protocols Extensions <[e-mail]>
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02
 
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?
 
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
[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


_______________________________________________
regext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/regext