Re: Changes we'd make to EPP

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