No expressions of preference have been expressed for over a month now :-( I think the authors deserve good guidance from the working group so they can progress their drafts, so let me be the first to express my motivation. I hope we can discuss this in Chicago, so more opinions are certainly needed on the mailinglist!
[chair hat off, personal opinion]
I have a strong preference for option 2, a generic organization object, and a
reseller mapping to such an organization object to identify resellers for a
domain.
Motivation:
1. Reusable.
An organization object could be reusable for future entities like
dns-operators, RDAP authorization, reporting entities etc.
We only need to define a new mapping for a new role, and not need a new
object and attribute definitions.
2. Mandatory attributes are local policy.
So far the discussion was on which attributes should be mandatory for a
reseller. I believe this is local policy, and doesn’t belong in the protocol
definition.
As I see it, only an organization’s name and ID could be mandatory
attributes, and all other attributes should be optional protocol wise.
We can define as many optional attributes we can think of, and off course
the protocol is still extensible after that, but at least we will have a
uniform definition for the most common ones.
The fact that the attributes are defined does not mean they need to be
filled in!!
It is up to local policy to decide which of these aditional organizational
attributes are mandatory to be mapped a certain role.
This will facilitate the basic requirements we have now for displaying
minimal reseller information in RDAP, but will allow organizations to
voluntarily supply extra information if necessary, and for registries to have
their own local policy in agreement with their local registrar and reseller
community. The protocol should be wider applicable than just ICANN registrars.
I will strongly object to additional mandatory attributes where that should be
defined in local policy by the registry in question.
3. Innovation.
Defining a more reusable organization object now will allow for easy
innovation later without having to go through the trouble of adapting the
protocol.
As an example: If I want to create a process to allow a DNS-operator to
adjust NS records with the consent of the registrar of record, I would only
need to make sure that the organization object has verified credential
attributes filled in, and registrar permission. I wouldn’t need to extend the
protocol to define these attributes, potentially differing from other
registries extensions for the same purpose.
4. Multiple roles.
Using a more generic "organization” object, not tagging an organization as
a one and only role as a reseller will allow an entity to have multiple roles.
This will decrease data to be maintained by both registry and the
organizations involved.
- --
Antoin Verschuren
Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
Op 9 feb. 2017, om 02:31 heeft Linlin Zhou <zhoulin...@cnnic.cn> het volgende
geschreven:
> Thanks for chair's support. We really need more options from WG to decide the
> drafts' direction.
> From the perspective of authors, we still think a reseller object is a more
> preferable way to fullfil the current requirements. But a more generic object
> is an optional choice for us to consider. And we need some discussion on the
> generic attributes for the new object.
> Any comments or opinions are warmly welcome.
>
> Regards,
> Linlin Zhou
>
> From: Antoin Verschuren
> Date: 2017-02-07 18:18
> To: regext
> Subject: [regext] Working group action required on
> draft-ietf-regext-reseller-ext-01.txt
> Dear working group,
>
> This is a request for action for you! Yes you! Reader of this mail,
> participant in this working group, or provisioning expert you forward this
> mail to.
>
> Resulting from our last session in Seoul and follow up discussion on the
> mailinglist a few weeks ago, we still need to make a clear decision on advise
> for the authors of the reseller drafts in which direction the working group
> wants these documents to progress. So far, there has not been an overwhelming
> feedback. We realize that not every draft may attract your attention, but for
> this working group to produce any quality documents, it’s vital that drafts
> are reviewed and multiple angle advise is given.
>
> This is a request to please take some time to review the purpose of the
> reseller drafts.
> Detailed XML review is welcomed, but to answer this one question that the
> authors are desperately waiting on, quantity of opinions and a good generic
> overview of EPP and future registration processes is most important.
>
> To summarize where we left off in Seoul, and the question that we need an
> anser for is the choice between 2 options that we have left to register
> resellers in EPP.
> I have renamed these option 1 and 2 (resulting from options C and D during
> the session in Seoul).
>
> Option 1: A dedicated reseller object.
> This is the pragmatic approach. We define an object that is only for
> resellers, as that is the only question on the table now.
> + Only define attributes needed for resellers now.
> - Hard to reuse or adjust after data is provisioned, and future roles will
> need a newly defined dedicated object as well.
>
> Option 2: A generic organization object that can also be used for resellers.
> This is the more future proof approach, where an organization object can be
> used for resellers now, but can be used for provisioning future roles as well
> (think dns-operator, auditor, RDAP access) by tagging the relationship role
> the organization has with other objects.
> + No need to reinvent the wheel in the future, multiple roles can exist,
> fewer objects needed.
> - More work now to define generic attributes and which attributes are
> mandatory or optional for a reseller role to provision. A need to define
> relations to other objects.
>
> It boils down to this simple question:
> Do we think every role an organization has needs a separate object in EPP, or
> do we think an organization can have more than one role in the registration
> process and we can identify this role in relation to other objects in EPP.
>
> Please state your choice and motivation as an advise to the authors by
> answering to this thread.
> Be aware that other options have already been discussed and were rejected. So
> please don’t make the choice more difficult by inventing an option 3.
>
> Regards,
>
> - --
> Antoin Verschuren
>
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
>
>
>
>
>
>
> Op 18 jan. 2017, om 06:40 heeft Linlin Zhou <zhoulin...@cnnic.cn> het
> volgende geschreven:
>
>> Dear Antoin,
>> Thanks for your review. Please see my feedback below.
>>
>> Regards,
>> Linlin Zhou
>>
>> From: Antoin Verschuren
>> Date: 2017-01-17 23:57
>> To: Gould, James
>> CC: Linlin Zhou; regext
>> Subject: Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt
>> Op 9 jan. 2017, om 20:05 heeft Gould, James <jgo...@verisign.com> het
>> volgende geschreven:
>>
>>> JG-The existing title “Extensible Provisioning Protocol (EPP) Reseller
>>> Mapping” follows the model set by the EPP Object RFC’s, as in EPP Domain
>>> Name Mapping (RFC 5731), EPP Host Mapping (RFC), and EPP Contact Mapping
>>> (RFC 5733) for Object-level Extensions as defined in RFC 3735.
>>
>> <snip>
>>
>>> JG-The titles for Command-Response Extensions in RFC 3735 has not been
>>> as consist. I believe it would be best to match the title convention of
>>> RFC 5910 for the Reseller Command-Response Extension as in “Reseller
>>> Extensions Mapping for the Extensible Provisioning Protocol (EPP)”.
>>> I recommend to use the convention “Protocol Extensions Mapping” for a
>>> Protocol-level Extension.
>>
>> Thank you for comparing, I hadn’t done all the consistency checking yet.
>> I agree with you that the object extension title is consistent and for
>> the command-response extension it is best to follow the RFC 5910 convention
>> as you suggest.
>>
>> [Linlin] The name of "draft-ietf-regext-reseller-ext-01" will be modified to
>> "Reseller Extensions Mapping for the Extensible Provisioning Protocol (EPP)"
>> to be consistent with RFC 5910.
>>
>>> Both of the abstracts need to be rewritten as I believe they are mixed up.
>>>
>>> JG-I believe to help with the mix up, the last sentence of the
>>> draft-ietf-regext-reseller-ext abstract can be modified to better reflect
>>> the purpose of the reseller command-response extension.
>>
>> Since the document names and titles can be made consistent but not too
>> revealing to non-epp-convention-experts, I agree that the abstract could be
>> of much help in avoiding confusion.
>>
>>> JG-Agreed that the introductions can be cleaned up and made more
>>> consistent. I also agree that the reference to ICANN should be removed.
>>> Your suggested text looks like a good starting point.
>>
>> Ok.
>>
>> [Linlin] The abstract and introduction will be revised as suggested to make
>> it more clear.
>>
>>> JG-A reseller may be a reseller of multiple registrars, but they would
>>> have a unique identifier per registrar. There is a direct relationship
>>> between the registry and registrar and the reseller and registrar, so
>>> although a reseller may use multiple registrars, they would be managed
>>> independently by the registrar and therefore would have a unique identifier
>>> per registrar.
>>
>> Ok, I understand this pragmatic approach. While it is a pity
>> registration process wise that a reseller does not have one unique ID per
>> registry, the idea behind one ID per registrar is because of the
>> assignment of the ID’s for maintenance by different registrars.
>>
>> My major concern for section 3 however is that it mixes up
>> "server/client” (EPP syntax) and "registry/registrar” (ICANN/Domain
>> registration syntax) which makes it confusing to read.
>> We should make a clear choice in what verbs to use. The above sentence
>> could also read:
>>
>> Ok, I understand this pragmatic approach. While it is a pity
>> registration process wise that a reseller entity does not have one unique
>> object per server, the idea behind one object ID per client is because
>> of the assignment of the ID’s for maintenance by individual clients.
>>
>>> And then add the syntax definition in [ID.draft-ietf-regext-reseller], and
>>> words on who assigns the ID according to what rules
>>> (first-come-first-serve/registry defined/registrarid preceded?)
>>>
>>> JG-It would be server defined but would be linked to the sponsoring
>>> registrar (client). We could look to have the identifier, which needs to
>>> be server-unique, along with a globally unique identifier (ROID) that
>>> includes the full set of unique identifiers for a reseller.
>>
>> If it is "server defined” as you intend, then there should be some text
>> that says that.
>> It must be clear to server operators that they need to define their ID
>> uniqueness algorithm as part of their local policy.
>> The server operator must define this algorithm itself as it is not
>> defined in this document.
>> It must be clear the server defines the algorithm, and not the client.
>> And then it’s strange that the client needs to assign the ID according
>> to the servers algorithm.
>> I would say that it’s then wise to leave the assignment of the ID to the
>> server and not the client like it is done with handles.
>>
>> The more general question I had is if this ultimate freedom for the
>> server to choose an algorithm is wise or necessary or that it adds more
>> complexity to the design choices the server operator needs to make.
>> We can give some examples to server operators on what sort of local
>> uniqueness policy server operators could use, like first-come-first-served,
>> fixed prefix per client-id, assigned by server algorithm, etc. , but my
>> experience is that everybody will copy what the first implementer has done,
>> as that is what people are used to.
>> (Registrars complain that every registry invents their own wheel).
>>
>> [Linlin] Some texts in draft-ietf-regext-reseller follow the pattern in
>> RFC5731, RFC5732 and RFC5733. Maybe we could add some words just like the
>> contact ID, for example, "Reseller identifiers are character strings with a
>> specific minimum length, a specified maximum length, and a specified format.
>> Reseller identifiers use the "clIDType" client identifier syntax described
>> in [RFC5730]."
>>
>> This leaves us with the question of the option C (dedicated reseller
>> role object) versus option D (generic role object for roles like
>> resellers/dns-operators/etc.).
>> Is there any progress or suggestion from the authors on this?
>>
>> [Linlin] Actually no, we are pending on this choice.
>>
>> Do we need to make another call on the mailing list to get a clearer
>> consensus or discussion?
>>
>> [Linlin] Yes.
>> Do the authors want to do this themselves, or do they need any help from
>> the chairs?
>>
>> [Linlin] It may be helpful if chairs could propose a call on the mailing
>> list to get more feedbacks. Thanks.
>>
>> regards,
>>
>> - --
>> Antoin Verschuren
>>
>> Tweevoren 6, 5672 SB Nuenen, NL
>> M: +31 6 37682392
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
