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