<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font size="+1"><font face="Lucida Grande">Surely there are many
other ways an individual could prove the original registration
date of a domain, other than it being in the WHOIS?</font></font></p>
<p><font size="+1"><font face="Lucida Grande">Stephanie Perrin</font></font><br>
</p>
<br>
<div class="moz-cite-prefix">On 2017-09-28 18:22, jonathan matkowsky
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CALsyHBniN2z+WfAzgkUuL=DQ-9fo-daxYFeRsvqvA==+TDn+4g@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">There is a lot going on in the last week, and I am
*still* playing catch up.
<div><br>
</div>
<div>
<div>I apologize with the religious high holidays at the end
of last week and my travel right before that, I dropped the
ball, but I want to emphasize that the poll that was
circulated framing the issue as to whether there is a
requirement for the Original Registration Date in the EWG
Final Report is not the issue in my humble opinion. The
issue is whether it was recommended. And it was. Very
clearly. And for good reasons. Some of those were specified
in the EWG Final Report on page 132, and illustrated in the
annex thereto. </div>
<div><br>
</div>
<div>There are many very important reasons why this
recommendation was being made from my perspective. I'm not
going to re-hash them. I am convinced that the reasons why
the EWG as a whole made this recommendation would be best
satisfied by the counter and indicator of unknown or yes
status. To just focus on the technical reasons why they
could have done a better job defining the Original
Registration Date element as a justification to dismiss the
*importance* of the element on the basis it was not required
would be unfortunate.</div>
<div><br>
</div>
<div>Domains may be registered and deleted throughout the day
literally within fifteen minutes apart. Others who lose
their domain inadvertently and then want to use that
original registration date as a point of reference in domain
recovery should not lose that opportunity. On the flip side,
to be fair, someone who is the subject of a UDRP deserves
the opportunity to point to the original registration date
as evidence the domain was allowed to lapse. When valuating
domain names for sale, it is important that there be a
public record that there may be a cloud on the title. etc.</div>
<div><br>
</div>
<div>The fact that it's unknown there is a prior existing
registration is important information. It let's people know
that the creation date does not mean it is the first time
the string has ever been created while at the same time
letting us know when we know for sure that there has been
such a prior registration in the future when deletions are
tracked. While technically that may be obvious to us here,
that is not necessarily obvious to many who rely on Whois.
So the fact it is set to unknown serves a very important
purpose. Furthermore, when it is actually known, that is
vital information to provide (nobody said registry operators
have to gather historical data that is burdensome or that
some might not even have). I am not convinced it is too much
to ask registry operators to keep track of deletions in the
future. Doing so may not be hard to implement and would meet
the recommendations of the EWG. Part of the work we are
doing here has to have long-term vision and not just whether
it is helpful in the short term for our personal or
commercial purposes at hand. A lot of people in future
generations are counting on us.</div>
<div><br>
</div>
<div>The particular date is not as important to meet the
underlying objectives of the EWG in coming up with this
recommendation. I would also not dismiss outright how this
counter will eventually serve an important function as an
indicator of severe abuse that is taking place behind the
scenes that nobody has easy access to see but can be in the
future would be more readily apparent from following the
EWG's recommendation in this regard (albeit, interpreting
their recommendation more liberally to satisfy the policy
considerations and purposes they identified). </div>
<div><br>
</div>
<div>All of that said, I recognize and respect that others may
disagree on this. I would at least then recommend that we
ensure that the specific ID number that must be collected
anyway from an engineering perspective is required to
actually be *displayed* to tenuously meet the objectives of
the EWG indirectly since its being exposed in a protocol
anyway by definition. While this is a lot more work and not
as helpful to many Internet users as the compromised
suggestion to meet their recommendation, at least we have
protection assuming there are historical records as readily
available as today and that people can point out the
different object ID numbers for these strings and explain
what that means. </div>
<div><br>
</div>
<div>Okay, I'm moving on unless there is a group that feels
based on what I've said, that we should at least re-visit
briefly. I recognize that there are *many* on this string
with a lot more experience than me and knowledge coming from
different vantage points, but feel it is important to at
least lay this out in case others agree, as I wasn't on the
call and couldn't chime in, in as a timely manner for which
I express my regrets.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Jonathan </div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Sep 22, 2017 at 7:45 AM,
Chuck <span dir="ltr"><<a
href="mailto:consult@cgomes.com" target="_blank"
moz-do-not-send="true">consult@cgomes.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">I want to request that
any members who think there is value in the 'counter'<br>
data element to please answer Paul's question: " So the
utility of the<br>
counter seems highly limited. Does it even<br>
deliver the usefulness that its proponents want it to?"
Please share what<br>
you think that value is on this list by Monday of next
week.<br>
<br>
Chuck<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg-bounces@icann.<wbr>org</a><br>
[mailto:<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg-<wbr>bounces@icann.org</a>]
On Behalf Of Paul Keating<br>
Sent: Thursday, September 21, 2017 8:32 AM<br>
To: Greg Aaron <<a href="mailto:gca@icginc.com"
moz-do-not-send="true">gca@icginc.com</a>>; Andrew
Sullivan <<a href="mailto:ajs@anvilwalrusden.com"
moz-do-not-send="true">ajs@anvilwalrusden.com</a>>;<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for
Original Registration<br>
Date<br>
<br>
And what is the intended purpose sought to be achieved?<br>
<br>
On 9/21/17, 5:15 PM, "Greg Aaron" <<a
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg-bounces@<wbr>icann.org</a>
on<br>
behalf of <a href="mailto:gca@icginc.com"
moz-do-not-send="true">gca@icginc.com</a>> wrote:<br>
<br>
>The upshot is that the counter would probably start at
"Unknown" for<br>
>all existing domains.<br>
>* Once implemented, the feature has little usefulness
until years in<br>
>the future, when some domains get re-registered and
those strings<br>
>accumulate some history.<br>
>* But many domains get renewed year after year. Those
wouldn't<br>
>accumulate counter history, and would be set to
Unknown either forever,<br>
>or for long periods if they are ever allowed to expire
and if they are<br>
>then re-registered. This is a significant portion of
domains. For<br>
>example .COM has an renewal rate of around 72%.<br>
><br>
>So the utility of the counter seems highly limited.
Does it even<br>
>deliver the usefulness that its proponents want it to?<br>
><br>
><br>
><br>
>-----Original Message-----<br>
>From: <a
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg-bounces@icann.<wbr>org</a><br>
>[mailto:<a
href="mailto:gnso-rds-pdp-wg-bounces@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg-<wbr>bounces@icann.org</a>]
On Behalf Of Andrew Sullivan<br>
>Sent: Thursday, September 21, 2017 10:49 AM<br>
>To: <a href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
>Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for
Original<br>
>Registration Date<br>
><br>
>On Thu, Sep 21, 2017 at 02:28:39PM +0000, Greg Aaron
wrote:<br>
>> The alternate proposal is a simple marker that
says whether there has<br>
>>been a known previous iteration of the domain
string, having been<br>
>>registered with a different ROID.<br>
>><br>
><br>
>Or a counter, of course, rather than just the marker.
From the point<br>
>of view of implementation in a database, I think these
two options are<br>
>approximately the same, so I prefer the counter
because it provides an<br>
>additional bit of data (that is, that the domain is
changing -- you can<br>
>watch it happen).<br>
><br>
>> And it still presents the same operational
problem: the registry has<br>
>>to figure out whether a string has existed
before. That is something<br>
>>registries are not designed to do. And they may
not have the<br>
>>necessary historical records. See the notes
below.<br>
>><br>
><br>
>Well, no, that's part of the point of the new
proposal: the registry<br>
>_doesn't_ have to figure that out, because the counter
can be set to<br>
>"unknown" (in a SQL database, you'd probably use
NULL). To support<br>
>this feature, however, the registry would have to
track deletions of<br>
>domain names in the future. So it wouldn't be free,
but it also<br>
>wouldn't be hard to implement. (Any real SQL
database, for instance,<br>
>could do this with an ON DELETE trigger.)<br>
><br>
>Best regards,<br>
><br>
>A<br>
><br>
>--<br>
>Andrew Sullivan<br>
><a href="mailto:ajs@anvilwalrusden.com"
moz-do-not-send="true">ajs@anvilwalrusden.com</a><br>
>_____________________________<wbr>__________________<br>
>gnso-rds-pdp-wg mailing list<br>
><a href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
><a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
>_____________________________<wbr>__________________<br>
>gnso-rds-pdp-wg mailing list<br>
><a href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
><a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
<br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<span
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)">******************************</span><span
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"><wbr>******************************</span><span
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"><wbr>*******<br>
</span><span
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)">This
message was sent from RiskIQ, and is intended only for the
designated recipient(s). It may contain confidential or
proprietary information and may be subject to confidentiality
protections. If you are not a designated recipient, you may not
review, copy or distribute this message. If you receive this in
error, please notify the sender by reply e-mail and delete this
message. Thank you.</span><span
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)">******************************</span><span
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"><wbr>******************************</span><span
style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;background-color:rgb(255,255,255)"><wbr>*******</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
</body>
</html>