Re: Changes we'd make to EPP

Sure, you can notify registrars all you want,that doesn't mean they will
or are required to do anything about it. On the other hand, if they don't
choose to continue to leave contact objects around for years, not linked
to anything (domains or other objects), then it's reasonable for a
registry to have a policy that allows them to declare them abandoned and
clean them up.

On the other hand, the registry really shouldn't be changing registrar
created/owned objects without synchronizing their activities somehow,
someway, as aptly put by others on the list.

This problem statement been repeated again and again for years.  Clearly,
there is a desire for a solution, although James you certainly entitled to
your opinion :-)

I still think the expiration idea on contacts is graceful and would
support that approach.  I think it informs registrars that contacts which
aren't linked don't last forever and if they are, the contacts auto-renew
so there's no work on the registrar side.

This approach means the registry isn't randomly mucking with their
contacts in a less predictable manner and having to update the registrar
somehow that they deleted their contact objects.

Some EPP registries have 2x or more abandoned contacts than active/linked
contacts (without naming them explicitly). Can you imagine that in .com?
A billion some-odd dead contacts sitting around in your escrow deposits.
   
I do think this could use a technical solution.

Michael Young




On 12-01-17 2:59 PM, "Gould, James" <[email protected]> wrote:

>I believe this is getting a bit complex and convoluted.  Contacts are
>first class objects in themselves as defined by RFC 5733, so they could be
>created at any point with no relation to a domain.  I don't believe the
>Registry should take any action to garbage collect them based on the lack
>of references from other objects like domains.  In systems like DotName a
>contact can be linked to other types of objects (emailfwd, defreg, etc.),
>so there is no hard dependency with being linked with a domain.  The same
>holds true for orphaned hosts, since hosts are not attributes of the
>domain unless the host attribute model is chosen.  It makes more sense to
>report on orphaned objects (contacts and hosts) out-of-band and for the
>Registries to reach out to the Registrars that have an unusually high
>number of them.  I'm not sure if we need a system solution to this that
>requires protocol changes.
>
>--
>  
>JG
> 
>
> 
>James Gould
>Principal Software Engineer
>[email protected]
> 
>703-948-3271 (Office)
>12061 Bluemont Way
>Reston, VA 20190
>VerisignInc.com
>
>
>
>
>
>
>
>On 1/17/12 2:50 PM, "Christopher Browne" <[email protected]> wrote:
>
>>On Tue, Jan 17, 2012 at 1:12 PM, Klaus Malorny <[email protected]>
>>wrote:
>>> - I just had an insane idea to avoid poll messages about the deletion
>>>of
>>>  contacts -- you may forget it just after you have finished
>>>  reading it (or even before): One could introduce an expiration date
>>>for
>>>  contacts. If a contact is created, it is set to one year in the
>>>future.
>>>  As long as the contact is used at least by one object, it is
>>>automatically
>>>  renewed, let's say a quarter before it expires. The registrar can
>>>either
>>>  track the expiration date (and perform a contact:info/check to check
>>>  its existence in case his recorded expiration date is in the past)
>>>  or simply create new contacts, as many registrars do it today.
>>>  For the registry, if the contact passes its expiration date, it is
>>>  simply deleted by the registry without any further fuss.
>>
>>I kind of like that, though I have a somewhat different implementation
>>thought, basically tying the expiration date to whether or not the
>>contact is linked.
>>
>>- Upon creation of a contact, it is initially not linked to anything.
>>Registry ties in an expiration date, and I have no disagreement with
>>the notion of that being 1 year in the future.
>>
>>- Upon linking a contact to an object (e.g. - to a domain), that
>>establishes LINKED status.  This *removes* that expiration date.
>>
>>- Any time a domain becomes unlinked (e.g. - the last link to a domain
>>or other object disappears), the registry ties in an expiration date
>>again.  The clock is ticking on its removal.
>>
>>It seems preferable to me to not have an expiry date when there is no
>>reason to want one.
>>
>>The semantics of what that date means and how it should be manipulated
>>seem rather strange at times when the contact is being 'actively
>>used.'  And if it's there, and reported, it seems likely to cause
>>confusion.
>>_______________________________________________
>>provreg mailing list
>>[email protected]
>>https://www.ietf.org/mailman/listinfo/provreg
>
>_______________________________________________
>provreg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/provreg


_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg