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

From: "James Galvin" <[email-masked]>
Date: Fri, 11 May 2018 09:32:14 -0400

This WGLC was intended to close on 27 April however, as you know, 
significant discussion started on the 20 April and the chairs have let 
the discussion come to a conclusion just this past week.

With that, version 06 of this document has been published and the chairs 
are declaring WGLC closed.  The document is now ready for submission to 
IESG for consideration as a Proposed Standard.

Pieter Vandepitte kindly volunteered to be the document shepherd for 
this document.   He can now begin his shepherd write-up.

Thanks to all!

Antoin and Jim

On 13 Apr 2018, at 9:21, James Galvin wrote:

> The document editors have indicated that the following document is 
> ready for submission to the IESG to be considered for publication as a 
> Proposed Standard:
>
> Extensible Provisioning Protocol (EPP) Organization Mapping
> https://datatracker.ietf.org/doc/draft-ietf-regext-org/
>
> Please indicate your support for the publication of this document.
>
> If any working group member objects to the publication of this 
> document please respond on the list by close of business everywhere, 
> Friday, 27 April 2018.  If there are no objections the document will 
> be submitted to the IESG.
>
> During the last call the chairs are looking for a document shepherd 
> for this document.  If you are interested in being the document 
> shepherd please let the chairs know.  The document editors cannot be 
> the document shepherd.
>
> If you’ve never been a document shepherd before don’t worry.  
> It’s a great way to understand the IETF process and your chairs 
> would be delighted to help you through it.
>
> Thanks,
>
> Antoin and Jim
> WG Co-Chairs

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 21 May 2018 05:19:00 +0200

> IESG for consideration as a Proposed Standard.

Isn't that a little rushed?

>From a quick search I have found about only 2 explicit mention of support of this document, from Pieter and Scott (as for myself I can not say I explicitely support it because I am still uneasy by the need for it or not seeing it and still not understanding some part of it like all the "role" part).

Also the document went into so many iterations during the period that it was basicaly impossible to follow
(one night I have tried reviewing its newest version by implementing it in my client... to find out in the morning that a new version went out so I kind of decided to stop giving it my time before it stabilizes in some way); some new comments even just popped out on the mailing-list yesterday.

So I feel uneasy process-wise. Based on the amount of iterations during WGLC it looks like to me that there is at least still some work needed on it, and I am not sure its current version correspond really to the working group consensus.

The above applies the same way for the two "organization" documents.

-- 
  Patrick Mevzek

---

From: Pieter Vandepitte <[email-masked]>
Date: Tue, 22 May 2018 08:57:38 +0200

Hi all,

Other thoughts? I think it's important as document shepherd to know whether we should move on or not.

Kind regards

Pieter

> On 21 May 2018, at 05:19, Patrick Mevzek <[email-masked]> wrote:
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Pieter Vandepitte <[email-masked]>
Date: Wed, 23 May 2018 13:36:11 +0200

Chairs,

Do we postpone the submission to IESG or do I continue my write-up?

@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 guess it's the fact that roles are defined as properties of the organization and at the same time as properties of the link?

Kind regards

Pieter

> On 22 May 2018, at 08:57, Pieter Vandepitte <[email-masked]> wrote:
> 
> Hi all,
>

---

From: "Gould, James" <[email-masked]>
Date: Wed, 23 May 2018 12:05:32 +0000

I would like to understand the concern around the use of the roles.  There are cases where an organization can play multiple roles (registrar, privacy proxy, dns provider, etc.) that helps defined what kind of links can be made to it.  The roles on the links between the objects and the organization is needed to qualify the type of relationship that exists between the object and the organization.  When the draft only dealt with the reseller, there was a single role.  When the working group agreed to define a more generic organization object for multiple purposes, the concept of the role was needed to support it.   

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com <http://verisigninc.com/> 

On 5/23/18, 7:36 AM, "regext on behalf of Pieter Vandepitte" <[email-masked] on behalf of [email-masked]> wrote:

    Chairs,

    
    Kind regards
    
    Pieter

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 24 May 2018 10:07:12 +0800

Dear Patrick,
During the WGLC, the drafts were updated from version 02 to 06 to response the comments on the mailing list. We are now waiting for our shepherd to give some feedbacks to optimize them. I think it is better to follow the version 06 of the org drafts if you have any comments.
As for the role definition, I think the generic organization way decided that we need to have a "role". You can trace the reseller drafts that there was no "role" element at all. Because we don't need a "role" to distinguish different types of organizations. The "Role Values Registry" was also disccused on the mailing list and got most people's support.

Regards,
Linlin

[email-masked]
 
From: Gould, James
Date: 2018-05-23 20:05
To: Pieter Vandepitte; Patrick Mevzek
CC: [email-masked]
Subject: Re: [regext] WGLC: draft-ietf-regext-org-02
I would like to understand the concern around the use of the roles.  There are cases where an organization can play multiple roles (registrar, privacy proxy, dns provider, etc.) that helps defined what kind of links can be made to it.  The roles on the links between the objects and the organization is needed to qualify the type of relationship that exists between the object and the organization.  When the draft only dealt with the reseller, there was a single role.  When the working group agreed to define a more generic organization object for multiple purposes, the concept of the role was needed to support it.   

—
JG

James Gould
Distinguished Engineer
[email-masked]
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190

 
    Chairs,

    
    Kind regards
    
    Pieter

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 24 May 2018 07:37:52 +0200

On Wed, May 23, 2018, at 14:05, Gould, James wrote:
> I would like to understand the concern around the use of the roles.  
> There are cases where an organization can play multiple roles 
> (registrar, privacy proxy, dns provider, etc.) that helps defined what 
> kind of links can be made to it.

Just an example (I do not wish really to revive the discussion) among others:
Imagine a registrar A for registry B, typically a ccTLD.
Registrar A creates an organization O in this registry B
It happens that O is a dns provider, let us say.
So it is created with this role.

Later O becomes ICANN accredited, for example. This is another role.

What totally escapes me: why shoud this be reflected in any way, through registrar A in registry B because O is provisioned there?

In short my main problem, and why I can not support this, is that I do not see the use case, besides for one registry that needs it to handle resellers, I doubt having seen another registry saying it will use it, so we are just paving the way to enable storing more data, where the world goes instead towards storing less or more carefully (see the current dramas around GDPR)

Not everythint that can be done should be done. This is the main point I will try to address in a separate email since it is a generic issue, not specifically related to this proposal.

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 24 May 2018 07:44:16 +0200

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

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 24 May 2018 12:37:55 +0200

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 <[email-masked]> wrote:
>

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 24 May 2018 12:43:16 +0200

Hi Linlin,

I did not know you waited on my to give feedback on optimizing the drafts. Regarding the remarks I gave you about the 'org' extension, you can apply what you suggested.

I also had a question about the roles and the use of the linked status. It would be better in my opinion to explicitly mention that somewhere or to give an example. 

I turn back to you for the review of the org-ext draft later.

Kind regards

Pieter

> On 24 May 2018, at 04:07, Linlin Zhou <[email-masked]> wrote:
> 
> Dear Patrick,
> [email-masked] <mailto:[email-masked]>
>  
> From: Gould, James <mailto:jgould=[email-masked]>
> Date: 2018-05-23 20:05
> To: Pieter Vandepitte <mailto:[email-masked]>; Patrick Mevzek <mailto:[email-masked]>
> CC: [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 24 May 2018 13:24:56 +0200

Hi

> On 24 May 2018, at 07:37, Patrick Mevzek <[email-masked]> wrote:
> 

I think this discussion will never end. There are 2 opinions (or maybe more) and everyone sticks to their own. Anyway, as a community, we managed to think of a specification which covers the needs of both camps. If you don't need roles, only allow the reseller role. I think that's the beauty of the solution.

Regarding storing more data. Maybe, yes, there are rumours that registries will become more and more thin, but this can take a long time (or never happen) and meanwhile, there are specific business needs to fulfil.

I just know about one GDPR drama, and I don't know whether it is a drama because of GDPR or the approach. But besides that, yes, we need to take into account policies and regulations. Therefor we need to think very careful when writing specs, but it should not hold us back of writing them. I think in this particular case, we did a pretty good job.

> Not everythint that can be done should be done. This is the main point I will try to address in a separate email since it is a generic issue, not specifically related to this proposal.

I agree with you, do not write specs just to have your name on an RFC. But again, as discussed in another conversation, it is very difficult, if not impossible to judge on the real needs of the community if there is very low participation (which is the main issue). Hence the importance of discussion groups like techops and others which are a valuable input for this group

Pieter

---

From: Peter Koch <[email-masked]>
Date: Thu, 24 May 2018 13:30:16 +0200

> I agree with you, do not write specs just to have your name on an RFC. But again, as discussed in another conversation, it is very difficult, if not impossible to judge on the real needs of the com…

the WG might want to reconsider the intended status, though.

-Peter

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 24 May 2018 15:22:32 +0200

On Thu, May 24, 2018, at 12:37, Pieter Vandepitte wrote:
> 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 think there was quite a lot of participation at the beginning, hence the change from reseller-centric to more generic. After that, my gut feeling is that no other registry needs it right now. Maybe in the future, and like you say they are waiting for it to be an RFC.
 
> I do not agree with you regarding not moving forward.

I did not say not to go forward, sorry if I miscommunicated.
On the contrary, the consensus is clear, even if the participation is not overwhelming. Go forward :-)

> 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

It is past LC like the chairs said, so the ship has sailed.

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Thu, 24 May 2018 13:30:37 +0000

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
[email-masked]

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

On 5/24/18, 6:38 AM, "regext on behalf of Pieter Vandepitte" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Patrick,

    
    
    Kind regards
    
    Pieter

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 May 2018 15:45:16 +0200

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:
---

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

---

From: "Gould, James" <[email-masked]>
Date: Fri, 25 May 2018 14:26:59 +0000

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.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 5/25/18, 9:45 AM, "regext on behalf of Antoin Verschuren" <[email-masked] on behalf of [email-masked]> wrote:

    ---

    —

    - --

    Antoin Verschuren

    M: +31 6 37682392

    regext mailing list

    [email-masked]

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 May 2018 18:19:00 +0200

> 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 he…

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 ;-))

---

From: "Gould, James" <[email-masked]>
Date: Fri, 25 May 2018 18:27:24 +0000

Antoin,

My feedback is embedded below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com<http://verisigninc.com/>

From: Antoin Verschuren <[email-masked]>
Date: Friday, May 25, 2018 at 12:19 PM
To: James Gould <[email-masked]>
Cc: Registration Protocols Extensions <[email-masked]>
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

Op 25 mei 2018, om 16:26 heeft Gould, James <jgould=[email-masked]<mailto:jgould=[email-masked]>> het volgende geschreven:

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).

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.

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.

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).

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 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
[email-masked]<mailto:[email-masked]>

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

Verisign.com<http://verisign.com/> <http://verisigninc.com/>

On 5/25/18, 9:45 AM, "regext on behalf of Antoin Verschuren" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    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<http://verisign.nl/> ?

    - --
    Antoin Verschuren

    Op 24 mei 2018, om 15:30 heeft Gould, James <jgould=[email-masked]<mailto:jgould=[email-masked]>> het volgende geschreven:

    > [email-masked]<mailto:[email-masked]>
    >
    > 703-948-3271
    > 12061 Bluemont Way
    > Reston, VA 20190
    >
    > Verisign.com<http://verisign.com/> <http://verisigninc.com/>
    >
    > On 5/24/18, 6:38 AM, "regext on behalf of Pieter Vandepitte" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
    >
    >    Hi Patrick,
    >
    >> On 24 May 2018, at 07:44, Patrick Mevzek <[email-masked]<mailto:[email-masked]>> wrote:
    >>
    >> [email-masked]<mailto:[email-masked]>
    >    [email-masked]<mailto:[email-masked]>
    > [email-masked]<mailto:[email-masked]>

    _______________________________________________
    regext mailing list
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/regext

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 May 2018 22:38:10 +0200

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: [email-masked]
The justification being that I’ve seen that term used more in wishful presentations than privacyproxy.

- --
Antoin Verschuren

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

> Verisign.com
> Op 25 mei 2018, om 16:26 heeft Gould, James <jgould=[email-masked]> het volgende geschreven:
> 
>

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 25 May 2018 23:39:27 +0200

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

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 27 May 2018 21:23:17 +0200

On Fri, May 25, 2018, at 15:45, Antoin Verschuren wrote:
> 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.

But yet I am not sure to have seen a lot of registries here saying that they need this extension, or that they plan to use it...

> 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.

Registrars can today publish reseller data in whois. This does not need to be sent to the registry, nor to have a specific EPP extension.

This is covered I think in ICANN world by section 1.4.2 of the whois specification:

"Additional data elements can be added at the end of the text format outlined below."
So registries/registrars could be free to add reseller data today, even without any change to EPP.

And in other worlds, where there is not necessarily a registrar whois, it all depends on the registry policy to see what will in whois, and no technical change could change this policy, so again I do not see how the EPP extension helps here.

> 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.

This is all true, probably, but how does it goes from there to "these operators need to exist as object in the registry database and be made under control of the registrars"? This sidestep many other points, like, one dns-operator for example, could be operator for domain names sponsored by registrar A and registrar B. Will both registrar A and B need to create an organization object for this same and only dns-operator organization? What exactly does this benefit to?

In a GDPR world you need more and more to be very specific about the data you collect, its use, and how you keep it. While it does not apply exactly as is here, I still fail to see why the registry database need to be populated with all this data.

And while I can understand James argument and design I think we are making things over complex without direct benefit, for what I understood the only use case applicable on the table is "storing reseller data in registry database (and maybe showing it in whois)".
For such a simple need, I think we are over-designing stuff.

Of course things would change a lot if many registries would come showing their support for this extension as it would help them for their various business needs.

-- 
  Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 28 May 2018 14:24:53 +0800

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

[email-masked]
 
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?

- -- 
Antoin Verschuren

Hi James,

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>.

- -- 
Antoin Verschuren

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

Antoin,

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com

 
 
One or more <org:role> elements that contains the role type, role      statuses and optional role id of the organization.

 

 

 

 

James Gould
Distinguished Engineer
[email-masked]
 
703-948-3271
12061 Bluemont Way
Reston, VA 20190

 

   

   

   
    
    - --
    Antoin Verschuren

---

From: "Gould, James" <[email-masked]>
Date: Mon, 28 May 2018 12:50:26 +0000

Antoin,

The parentID does not define ownership.  As with other EPP objects, the clID attribute defines ownership / sponsorship.  The parentID exists to enable creating a hierarchy of organizations under a particular sponsoring client, like a registrar that supports a reseller channel of more than one layer.

A reseller cannot be a reseller for more than one registrar with the registry.  The organization created by a registrar would be sponsored by that registrar and would not be able to be associated with another registrar or linked to an object sponsored by another registrar.  The protocol does not dictate the server policy, but I imagine that any organization linked to organizations sponsored by the current registrar would get automatically unlinked upon the completion of the registrar transfer.

There should be no possibility of object hijacking if the scope of an organization is kept at the level of the creator.  The registry itself could be the sponsoring client of an organization, such as the registrar, and could be the case for other organizations like the dns-operator.  There is only one sponsoring client that defines management control, where I don't see the possibility that an organization can be a "reseller" with registrar A and could be a "dns-operator" for domains at registrar B.  I don't view the "reseller" role for an organization applicable where the sponsoring client is at the registry level.  The "reseller" organizations should be scoped to the sponsoring "registrar" client.

Yes, there is certainly the possibility that at the registry level a single organization in the real-world is represented as multiple organization instances created by separate registrars.  If there was an organization that is a reseller for more than one registrar, each registrar would create a separate organization instance with a unique organization iD for the reseller.

I hope this helps.

Thanks,

Jim

________________________________
From: regext [[email-masked]] on behalf of Antoin Verschuren [[email-masked]]
Sent: Friday, May 25, 2018 5:39 PM
To: Registration Protocols Extensions
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

- --
Antoin Verschuren

Op 25 mei 2018, om 22:38 heeft Antoin Verschuren <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

Hi James,

3.2.  Organization Roles

3.2.1.  Role Type

      Value: dns-operator

      Registrant Name: IESG

      Registrant Contact Information: [email-masked]<mailto:[email-masked]>

- --
Antoin Verschuren

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

Antoin,

—

JG

James Gould
Distinguished Engineer
[email-masked]<UrlBlockedError.aspx>

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

From: Antoin Verschuren <[email-masked]<mailto:[email-masked]>>
Date: Friday, May 25, 2018 at 12:19 PM
To: James Gould <[email-masked]<mailto:[email-masked]>>
Cc: Registration Protocols Extensions <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

James Gould
Distinguished Engineer

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

http://verisigninc.com/>

    - --
    Antoin Verschuren

    Op 24 mei 2018, om 15:30 heeft Gould, James <jgould=[email-masked]<mailto:jgould=[email-masked]>> het volgende geschreven:

    > http://verisigninc.com/>

---

From: "Gould, James" <[email-masked]>
Date: Mon, 28 May 2018 13:00:16 +0000

> For such a simple need, I think we are over-designing stuff.

The different design options were discussed at IETF 98, where a targeted solution for resellers is certainly simpler than supporting a generic organization.  The direction from the working group was to support the more generic and complex organization.  I believe the two use cases that have value now is the reseller use case and the registrar use case.  The registrar information should be available directly available from with EPP instead of having to use WHOIS / RDAP.  I see having a generic organization object and extension as being a better solution than attempting to create role-specific objects and extensions for reseller, registrar, and other organization types that come up in the future.  

Jim

________________________________________
From: regext [[email-masked]] on behalf of Patrick Mevzek [[email-masked]]
Sent: Sunday, May 27, 2018 3:23 PM
To: [email-masked]
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-org-02

--
  Patrick Mevzek

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 28 May 2018 21:29:25 +0200

Op 27 mei 2018, om 21:23 heeft Patrick Mevzek <[email-masked]> het volgende geschreven:

> "Additional data elements can be added at the end of the text format outlined below.”

Ah yes, let’s take the solution of "we can put everything in one non-parseble TXT record like DNS can do too if we fail proper design and really want to” ;-)
Sorry for the sarcasm Patrick, but that one was a too open goal ;-)

> This is all true, probably, but how does it goes from there to "these operators need to exist as object in the registry database and be made under control of the registrars"? This sidestep many oth…

That was my question and worry too, and the answer unfortunately is yes, as ownership of an object needs to be clear to prevent hijacking or no responsibility for data.
It’s a choice between two bad’s I agree, but having an organization in the DB more than once under different registrars with different ID’s is less bad than having objects nobody maintains or fights over.

> In a GDPR world you need more and more to be very specific about the data you collect, its use, and how you keep it. While it does not apply exactly as is here, I still fail to see why the registry…

You forget to see that this will benefit registries that want to do the right thing where they are now limited by protocol. It allows innovation. I’ve seen registries that want to add reseller data in whois/RDAP at their registrar’s request, registries that want dns-operators to be able to roll their registrant’s DNSSEC keys, they want to be transparent as tho which organization has extended RDAP access, etc. And the registrars are still in control over who they trust with these limited registry credentials, but in the end they will save costly customer support and have more extended service if they automate.

> For such a simple need, I think we are over-designing stuff.

If that were the only use case, I would agree with you.
It may look like overdesigning now if that were the only use case, but if we don’t add structure now, it will be hard to go back once unstructured objects are already populated.
We took the challenge of doing more work now, to have quicker innovation later. And I see more use cases than just the reseller one.

regards,

- --
Antoin Verschuren

- --
Antoin Verschuren

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 28 May 2018 22:40:44 +0200

On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote:
> Ah yes, let’s take the solution of "we can put everything in one non-
> parseble TXT record like DNS can do too if we fail proper design and 
> really want to” ;-)

I am not sure to see where in the text it says that formatted content is forbidden, can you pinpoint it to me?

Also, I fail to see how any EPP extension would have any impact here
(in the sense that: you can change what is displayed in whois irrespective to what happens on the EPP channel).

> You forget to see that this will benefit registries that want to do the 
> right thing where they are now limited by protocol.

I asked many times who these registries are, I still fail to see broad consensus by registries to implement these extensions (I do not count silence as being "I agree" but just as "I do not care" or "I am not following these discussions, I do not know what to think about it"). Maybe they are thousands of them just anxiously waiting for this work to become an RFC (like it never happened in the past with registries implementing even core EPP documents before they became RFCs...), or maybe there are just not many of them needing all this...

Noone knows but I have my ideas in which case we are.

> It allows innovation. 

Innovations do not need RFCs, that can happen before.
This would be a separate topic.

> I’ve seen registries that want to add reseller data in 
> whois/RDAP at their registrar’s request, registries that want dns-
> operators to be able to roll their registrant’s DNSSEC keys, they want 
> to be transparent as tho which organization has extended RDAP access, 
> etc. And the registrars are still in control over who they trust with 
> these limited registry credentials, but in the end they will save costly 
> customer support and have more extended service if they automate.

Maybe. At least this is not shown by discussions here, which is sad.
Also, I am still not sure the proposed extensions solve all of these problems anyway. Especially if you take into account the drawbacks as any solution has both benefits and drawbacks, nothing is a pure win.

> We took the challenge of doing more work now, to have quicker innovation 
> later. And I see more use cases than just the reseller one.

Maybe. I am not convinced by the data proposed on the table. There may be a lot more elsewhere, but here I do not see.

Anyway, this is moot. The extensions will go forward and become an RFC and then we will be able to jauge really the interest by registries and how it is implemented...

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 28 May 2018 22:48:25 +0200

Antoin,

On Mon, May 28, 2018, at 22:40, Patrick Mevzek wrote:
> (in the sense that: you can change what is displayed in whois 
> irrespective to what happens on the EPP channel).

In your quote you missed the other part which is basically: all domain names are not under ICANN policies.

So for all other TLDs currently can you let me know which protocol limitations currently forbid registry to add formatted content in their whois or, let us say just decide to implement RDAP to start with? Do you really think there are almost none because of protocol limitations, especially in the EPP channel, or maybe for other reasons?

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Tue, 29 May 2018 14:46:02 +0000

There are many registries that participate in this working group that have spoken on the list or at the working group meetings on these extensions, so I’m really not sure what it means to have “broad consensus by the registries to implement”.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 5/28/18, 4:41 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote:

    > Op 27 mei 2018, om 21:23 heeft Patrick Mevzek <[email-masked]> het

    > volgende geschreven:

    --

      Patrick Mevzek

    regext mailing list

    [email-masked]

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 30 May 2018 22:24:17 +0200

> In your quote you missed the other part which is basically: all domain names are not under ICANN policies.

I didn’t want to go in that discussion, but I’m on your side on that one.

> So for all other TLDs currently can you let me know which protocol limitations currently forbid registry to add formatted content in their whois or, let us say just decide to implement RDAP to star…

Perhaps it’s not only protocol limitations, or perhaps limitation the wrong word, it’s more the pinpointed ICANN RRR model I think that can only be provisioned for now.
I remember a CENTR meeting where ccTLD’s tried to get consensus over if we could harmonize EPP extensions so registrars would not have to code differently for every TLD.
This was before EPPEXT existed.
We all thought this would be a good idea.
But half the registries concluded that they wanted to stick to their own extensions because they felt local legislation or their local constituencies required them so, and the other half had the standpoint that they would only implement as followers, after extensions would be standardized.

Again Patrick, I share your concern of complexity, and we shouldn’t build something nobody uses.
I also shared your concern for double labeling both at the organization and link level, but James managed to convince me it’s a choice between two bad’s where the responsibility of registrars over records they maintain outscores double entries in the database for organizations that do anything for anybody.

The reseller draft was originally requested and supported by cnnic, sidn and dns belgium who also had the intend to implement. If not this standard then their own extension.
Other registries didn’t immediately acknowledge the need for resellers unless mandated by (ICANN) policy, but there was consensus that if we were to standardize something to accommodate resellers, it should be reusable for other emerging "Internet identifier registration related roles" as well. This was not only TLD registries that had an opinion, and I remember some hesitation especially by ICANN registrars as well because they didn't want extra work, but third party dns-operators, ICANN related policy makers, RIR’s, registrants and plain IETF protocol guardians also have an equal voice in the IETF process, even though they don’t implement.

- --
Antoin Verschuren

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 31 May 2018 03:39:35 +0200

On Wed, May 30, 2018, at 22:24, Antoin Verschuren wrote:
> I remember a CENTR meeting where ccTLD’s tried to get consensus over if 
> we could harmonize EPP extensions so registrars would not have to code 
> differently for every TLD.
> But half the registries concluded that they wanted to stick to their own 
> extensions because they felt local legislation or their local 
> constituencies required them so, and the other half had the standpoint 
> that they would only implement as followers, after extensions would be 
> standardized.

I have thought for a long time about EPP standardization and I came into conclusion that if consolidation does not happen it is for reasons outside of the technical realm. Hence my belief no technical solutions would change any of it.

> This was not only TLD registries that had an opinion, 
> and I remember some hesitation especially by ICANN registrars as well 
> because they didn't want extra work, but third party dns-operators, 
> ICANN related policy makers, RIR’s, registrants and plain IETF protocol 
> guardians also have an equal voice in the IETF process, even though they 
> don’t implement.

While every voice is welcome at the table, I still like and favor the idea of "running code". Besides rough consensus which you are all saying we have, so let us go forward on this topic and standardize this extension that so many actors want or agree to.

-- 
  Patrick Mevzek