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
zhoulin...@cnnic.cn
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: +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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
