[gnso-rds-pdp-wg] Proposed Agreement for Original Registration Date

benny at nordreg.se benny at nordreg.se
Mon Oct 2 01:01:47 UTC 2017


I would say that an expire and then a following delete will trick a delete of the element date that sounds reasonable

Sent from my iPhone

On 2 Oct 2017, at 07:23, Paul Keating <paul at law.es<mailto:paul at law.es>> wrote:

I have still not heard a good reason for this element.

If it will not track from the actual 1st date what is the point?

Does expiration trigger a new date?  If so, what point during expiration?


Sent from my iPad

On 30 Sep 2017, at 21:54, Rod Rasmussen <rod at rodrasmussen.com<mailto:rod at rodrasmussen.com>> wrote:



On Sep 30, 2017, at 9:30 AM, Stephanie Perrin <stephanie.perrin at mail.utoronto.ca<mailto:stephanie.perrin at mail.utoronto.ca>> wrote:


Surely there are many other ways an individual could prove the original registration date of a domain, other than it being in the WHOIS?

Stephanie Perrin

\

An excellent point.

As a member of the EWG and a proponent of capturing the original registration date during our work there, I think its important to look at this a bit more holistically.  The EWG report covers, to some extent, why people desire this information and what it is used for - "is" being the operative word here, not "could be".  Today, we do not have this collected or published in a consistent, transparent, complete, or auditable way.  It is done largely by third parties (often paid) tracking this information over time as they make observations.  That lack of rigor is clearly problematic in some of the use cases where such information can be presented as "evidence" of prior registration by a particular party that may be attached to an IP rights issue like a UDRP filing for instance.  That doesn't even touch on the questions surrounding rights, legality, etc. of third parties doing this in the first place.

One of the hopes with proposing this data out of the EWG was to address these issues.  The conversation we've had here and that I've had with other technical experts on the practicalities of doing this really well (well enough to be considered reliable for the various use cases) are going to be fairly difficult to accomplish, and likely fairly expensive.  None of us know for sure if we could do things like backfill databases, closely track changes going forward, etc. to a sufficient level.  It is clear to me from my further discussions with folks I trust to know this well that this will at the very least be a pretty heavy lift.  So I personally voted in the latest poll to drop this as a requirement for the RDS at this point of time.  Some more research may well be warranted, but it doesn't seem like we should be spending further time on it in this group for now.

That all said, we still have the underlying issues that are driving people to want this information, and this is still related to our work, if tangentially.  If we do not include this in an RDS, other people will continue to gather information to be able to answer questions around original registration dates (when, how, who?).  I would argue that there will be many other types of data that we will decide does not go into the RDS itself (that potentially could) that others will then continue to collect and disseminate outside of the RDS and its policies/processes.  This takes me back to Stephanie's question above.  The answer is "yes, but".  The "but" being that the data will not be as robust and reliable as needed for the purpose at hand, and it will certainly have a host of legal and rights questions attached to it.  Those problems will not be solved unless we, or some other ICANN-related policy making process, address the issues surrounding third party collection and dissemination of RDS data.

I definitely do not propose we take up a discussion about this topic area now, as we are already going so slowly, I often think that we are in reverse, but I do think we need to put this down as a marker that we will have to either deal with ourselves or recommend that subsequent policy work address.  If people want certain types of RDS-related data and it has non-trivial value to them, they will find ways of obtaining it using RDS data - some grayer than others.  The more we cover as part of the RDS and its related policies and processes, the easier it is to actually enforce policies and the intent of various laws while accommodating those market forces.  Those areas we are silent on or ignore will continue to create issues for the community to address in one way or another.

Cheers,

Rod
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org<mailto:gnso-rds-pdp-wg at icann.org>
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20171002/901e52f9/attachment.html>


More information about the gnso-rds-pdp-wg mailing list