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