Dear all,
Thanks Rik and James for your feedbacks.
I've listed the elements and whether it is required in the reseller draft.
Please send comments if you have other suggestions.
o <reseller:id> required
o <reseller:roid> required
o <reseller:state> required
o <reseller:parentId> optional
o One or two <reseller:postalInfo> elements
* <reseller:name> required
* <reseller:addr>
+ <reseller:street> One, two, or three optional
+ <reseller:city> required
+ <reseller:sp> optional
+ <reseller:pc> optional
+ <reseller:cc> required
o <reseller:voice> optional
o <reseller:fax> optional
o <reseller:email> optional
o <reseller:url> required if it has
o Zero or more OPTIONAL <reseller:contact>
o <reseller:clID> required
o <reseller:crID> required
o <reseller:crDate> required
o <reseller:upID> required if it has
o <reseller:upDate> required if it has
o <reseller:disclose> optional
Regards,
Linlin Zhou
From: Rik Ribbers
Date: 2016-08-22 23:11
To: James Gould
CC: Linlin Zhou; regext
Subject: Re: [regext] reseller drafts reviews
Hi James,
On 22 Aug 2016, at 16:02, Gould, James <[email protected]> wrote:
Rik,
Your response made me think a little bit more around the problem that is being
solved. I see 2 problems that could be solved by formally defining the
reseller and linking the reseller with objects in the registry:
Displaying the Reseller information in RDDS (RDAP). Right now it is the
reseller name that needs to be displayed, but what if more information is
needed later like E-mail, URL, Address, Contacts, etc.?
Exactly the reason for creating an object (and going for option C in Linlin’s
proposal). However if were are going to todo this for resellers specific we are
going to have to create another EPP extension for every ”new” instance in the
ecosystem as it evolves. I can image we do this for DNS-operators, but also for
registrants (where the registry provides some additional services to
registrants and the current contact mapping is not sufficient).
Enable registrars to set security, policy, and reporting options for reseller’s
at the registry level. I can see many different use cases here that we’ve not
yet fully discussed.
Agreed this has not been discussed, and I do see some use cases. Although I
doubt we would configure these options through EPP. I would provision this
through some customer portal where the registrar can do this (either through a
web interface or REST API).
I don’t want to fall into the “RDDS Copy Authoritative Data” anti-pattern in
solving problem #1 by having the registrars or even the resellers copying
authoritative data down to the another party (registry) to display as if it
were authoritative. The registry does not need any additional information
(address, voice, fax, email, url, contacts, disclose) for a reseller in solving
problem #2, since the identifier, the name, and the relationship to the
registrar and to the registry objects is important.
To solve both problems without falling into the “RDDS Copy Authoritative Data”
anti-pattern, the following is needed:
Need to be capable of defining an object in the registry via the EPP Reseller
Mapping with the minimal attributes required to solve problem #1 and #2.
Specifically the following information is needed:
Identifier - Registry unique identifier that could be client specified or
server generated.
If the GURID is indeed globally unique this is merely a technical identifier
(primary key) and it is not even necessary in the EPP xml.
Name - Name of the Registrar that can be more easily referred to.
GURID (Globally Unique Identifier) - This is similar to the GURID (IANA ID) for
registrars or could be derived from it to create a globally unique identifier
for resellers.
RDAP URL - URL that can be referenced in the Registry RDAP to get the reseller
information. Any additional information associated with the Reseller can be
retrieved by the authoritative source for this information and following the
local privacy laws and regulations. Although the reseller name is the only
attribute that we’ve discussed thus far in RDAP, the technical solution should
support additional information that can satisfy the local privacy laws and
regulations effectively.
Interesting idea, we start mixing EPP and RDAP here…. For the EPP specification
I would add an URL in the EPP XML and in the server policy I would
state/specify that this must be an RDAP specific URL. What if there is a ccTLD
with no RDAP support, one can simply add the website of the reseller. But I
agree that these fields are the bare minimum.
Need to be capable of linking registry objects to the reseller object via the
EPP Reseller Extension. The only attribute that is needed is the reseller
identifier. If more information is needed, the EPP Reseller Mapping can be
used to get the GURID and the RDAP URL for subsequent lookups. We don’t need
or want any additional attributes in the links. What would happen if the
reseller name changed or any other relevant reseller information changed? I
don’t believe we would want to require an update to a large set of registry
objects.
+1, exactly what I had in mind.
Thoughts?
—
JG
<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
James Gould
Distinguished Engineer
[email protected]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com
On Aug 22, 2016, at 5:30 AM, Rik Ribbers <[email protected]> wrote:
Linlin,
On 15 Aug 2016, at 09:54, Linlin Zhou <[email protected]> wrote:
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
This seems to be the minimum-viable-product. However I can image you might want
to add more fields, at least an email address for contacting the reseller…. so
we need some sort of object.
B. reuse contact object
This would be my personal preferred object, however in our case the RFC5733
contact object did not have all the required fields…. so we need some sort of
contact object or reseller object
C. a independent reseller object, such as defined in draft-ietf-regext-reseller
Given the use-case this might seem interesting for the specific reseller
use-case. However there are more use-cases on the horizon (e.g. 3rd party DNS
operator). So are we going for a reseller specific solution this is the best
(with a minimum set of required fields). However we might want to consider
creating a more generic extension (like the entity in RDAP) which we can use
for other objects to be labelled with.
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.
If this is the ICANN policy (haven’t look for it yet though), we might want to
consider adding the name as an optional field to the
draft-ietf-regext-reseller-ext draft. So implementers have 2 choices. Implement
only draft-ietf-regext-reseller-ext with the name field (so the domains can be
simply labelled with a reseller name) or implement the full EPP object with
the draft-ietf-regext-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?
Conclusion:
Although at first it seems a little bit of overkill I came to the conclusion
Option C is the best option, with the remarks that we need a minimum set of
required fields. And optionally we could add the name back into the
draft-ietf-regext-reseller-ext if this makes it less effort to comply with
ICANN policies for implementers.
Gr,
Rik
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
