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

Thu Sep 28 22:22:58 UTC 2017

There is a lot going on in the last week, and I am *still* playing catch
up.

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.

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.

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.

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.

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).

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.

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.

Cheers,
Jonathan

On Fri, Sep 22, 2017 at 7:45 AM, Chuck <consult at cgomes.com> wrote:

> I want to request that any members who think there is value in the
> 'counter'
> data element to please  answer Paul's question:  " So the utility of the
> counter seems highly limited.  Does it even
> deliver the usefulness that its proponents want it to?"  Please share what
> you think that value is on this list by Monday of next week.
>
> Chuck
>
> -----Original Message-----
> From: gnso-rds-pdp-wg-bounces at icann.org
> [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Paul Keating
> Sent: Thursday, September 21, 2017 8:32 AM
> To: Greg Aaron <gca at icginc.com>; Andrew Sullivan <ajs at anvilwalrusden.com>;
> gnso-rds-pdp-wg at icann.org
> Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original Registration
> Date
>
> And what is the intended purpose sought to be achieved?
>
> On 9/21/17, 5:15 PM, "Greg Aaron" <gnso-rds-pdp-wg-bounces at icann.org on
> behalf of gca at icginc.com> wrote:
>
> >The upshot is that the counter would probably start at "Unknown" for
> >all existing domains.
> >* Once implemented, the feature has little usefulness until years in
> >the future, when some domains get re-registered and those strings
> >accumulate some history.
> >* But many domains get renewed year after year.  Those wouldn't
> >accumulate counter history, and would be set to Unknown either forever,
> >or for long periods if they are ever allowed to expire and if they are
> >then re-registered.  This is a significant portion of domains.  For
> >example .COM has an renewal rate of around 72%.
> >
> >So the utility of the counter seems highly limited.  Does it even
> >deliver the usefulness that its proponents want it to?
> >
> >
> >
> >-----Original Message-----
> >From: gnso-rds-pdp-wg-bounces at icann.org
> >[mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Andrew Sullivan
> >Sent: Thursday, September 21, 2017 10:49 AM
> >To: gnso-rds-pdp-wg at icann.org
> >Subject: Re: [gnso-rds-pdp-wg] Proposed Agreement for Original
> >Registration Date
> >
> >On Thu, Sep 21, 2017 at 02:28:39PM +0000, Greg Aaron wrote:
> >> The alternate proposal is a simple marker that says whether there has
> >>been a known previous iteration of the domain string, having been
> >>registered with a different ROID.
> >>
> >
> >Or a counter, of course, rather than just the marker.  From the point
> >of view of implementation in a database, I think these two options are
> >approximately the same, so I prefer the counter because it provides an
> >additional bit of data (that is, that the domain is changing -- you can
> >watch it happen).
> >
> >> And it still presents the same operational problem: the registry has
> >>to figure out whether a string has existed before.  That is something
> >>registries are not designed to do.  And they may not have the
> >>necessary historical records.  See the notes below.
> >>
> >
> >Well, no, that's part of the point of the new proposal: the registry
> >_doesn't_ have to figure that out, because the counter can be set to
> >"unknown" (in a SQL database, you'd probably use NULL).  To support
> >this feature, however, the registry would have to track deletions of
> >domain names in the future.  So it wouldn't be free, but it also
> >wouldn't be hard to implement.  (Any real SQL database, for instance,
> >could do this with an ON DELETE trigger.)
> >
> >Best regards,
> >
> >A
> >
> >--
> >Andrew Sullivan
> >ajs at anvilwalrusden.com
> >_______________________________________________
> >gnso-rds-pdp-wg mailing list
> >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
> >https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> 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
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>

-- 
*******************************************************************
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.

*******************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170928/58750944/attachment.html>