Hi Antoin,
Thanks for your suggestion and I have some clarifications of your suggestion.
Actually in the reseller draft, we've thought the issue about registrar and
reseller objects. The reseller has pretty much the same attributes that would
be captured for a registrar if a registrar could be provisioned via EPP. We
really see the reseller object as more of an account object, where a registrar
is an account without a parent. So in section 3.4, we've defined the parent
identifier to show the hierarchy.
In the hierarchy discussion, we've drawn a simple graph of reseller relations
as below,
Registry------------------------
| |
|-Reseller---------------- |-Registrar
| |
|-N-Tier Reseller |-Reseller Customer
|
|-Reseller Customer
Registrar - Has direct contractual relationship with the registry and direct
access to the registry without any sub-accounts
Reseller - Has direct contractual relationship with the registry and direct
access to the registry with sub-accounts. A reseller is really a Registrar
with sub-accounts.
N-tier Reseller - Does not have a contractual relationship with the registry or
direct access to the registry with sub-accounts.
Reseller Customer - Does not have a contractual relationship with the registry
or direct access to the registry without any sub-accounts.
In our opinion, it may be easier for everyone to understand the scope of the
object mapping, so we leave it as strictly a Reseller Object Mapping. As there
is no object mapping for registrar, if we want to define a more general object
including registrar and reseller, we may need a type attribute to differentiate
them and may have some other adjustments which I am not thinking very clearly.
Regards,
Linlin Zhou
From: Antoin Verschuren
Date: 2016-08-15 17:38
To: Linlin Zhou
CC: regext
Subject: Re: [regext] reseller drafts reviews
Hi Linlin,
I must admit I haven’t compared the proposed reseller structure to that of a
registrar, but what happens when a reseller suddenly wants to become a
registrar (or a registrar that will become a reseller under a larger
registrar)? Use cases that I think happen regularly.
Is it just a matter of adding or removing a reseller:parentId?
I’d say option D to reuse the same fields for a reseller as a registrar, but
with business logic that makes a lot of fields optional that would be mandatory
for a registrar without a parentId. I mean, a reseller is an entity, just like
a registrar but with different rights and obligations towards the registry,
right? Would that work?
What is shown in RDAP is another matter, but at least we don’t need to reinvent
and maintain a new structure, and we only need to agree on which fields are
optional for which role, which may even be local policy.
Also thinking ahead of the possibility to administer 3th party dns-operators
with limited rights agreed upon by the parent registrar, which might encounter
the same question..
Just a thought.
- --
Antoin Verschuren
Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
Op 15 aug. 2016, om 09:54 heeft Linlin Zhou <zhoulin...@cnnic.cn> het volgende
geschreven:
Dear all,
The reseller drafts were suggested to have more reviews in last IETF meeting.
All of the issues raised on the mailing list have been solved and updated in
the latest version. Any more review or comments on these two drafts are
appreciated.
Regarding the draft-ietf-regext-reseller, we may have some choices of keep
reseller information in my mind,
A. an ID and a name only
B. reuse contact object
C. a independent reseller object, such as defined in draft-ietf-regext-reseller
The RDAP may only need a name displayed in response but there are still some
other information we need such as the contact or parent registrar of a
reseller. So option A may not seem as a good choice. Some registries have
already use contact to keep reseller information, but after discussion we found
that reseller and contact are not totaly the same. The reseller is a object
that could have one or more contacts and it has hierarchical structure. So
option B is also not take into consideration. Finally we decided to define a
reseller object to full fill the existing and possible future requirements.,
which is a flexible way for any changes. Thoughts?
Regards,
Linlin Zhou
_______________________________________________
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
