You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a domain manager
I want to ensure my domain stays registered to me (and do that without much work)
so that I can keep using it
As the .gov registry
We want to ensure we have current contact information for our registrants
so we can reach them when needed
Acceptance Criteria
Document the pros and cons of keeping or departing from the standard renewal model, in light of our goal to increase the use of .gov by US-based governments.
If we depart from normal "please click here each year" annual renewals, design an intuitive UX/UI for users than supports our requirement for accurate contact info.
Additional Context
The concept of a domain's registration and expiration are components of a domain's lifecycle for all (?) generic TLDs. We aren't bound to follow this pattern, though, and in a few ways, we already don't: we do not automatically delete or place on hold domain names that are past their expiration date. We don't believe that's an appropriate, fair, or safe default for government domain names.
However, a renewal date is a useful forcing function. Though we're not collecting payment like other TLDs, we use the renewal date to require a registrant confirm or update their org's contact information. (It's a successful tactic, and we've used it to nudge users to create public security contacts, which has gone from idea to a >70% uptake since 2018.) But we could request or confirm this information at other times instead of annually, and that could have a bearing on "extending" an expiration date automatically. We could also consider other factors, like whether a domain is actually being used on the internet – which is the behavior we want to incentivize, anyway.
Historically (and at launch), the only reason users come to our registrar is to request, set up, and renew their domain. We'll add manage to that list soon, changing the dynamic by offering DNS hosting and other supporting services in-registrar.
Most important aspect of this is that we have current and accurate CONTACT information for each domain. The renewal time is appropriate for this update.
We're going to tackle this in a more standard way, according to expectations with other registrars. Closing this in favor of tickets to describe that experience instead.
Story
As a domain manager
I want to ensure my domain stays registered to me (and do that without much work)
so that I can keep using it
As the .gov registry
We want to ensure we have current contact information for our registrants
so we can reach them when needed
Acceptance Criteria
Additional Context
The concept of a domain's registration and expiration are components of a domain's lifecycle for all (?) generic TLDs. We aren't bound to follow this pattern, though, and in a few ways, we already don't: we do not automatically delete or place on hold domain names that are past their expiration date. We don't believe that's an appropriate, fair, or safe default for government domain names.
However, a renewal date is a useful forcing function. Though we're not collecting payment like other TLDs, we use the renewal date to require a registrant confirm or update their org's contact information. (It's a successful tactic, and we've used it to nudge users to create public security contacts, which has gone from idea to a >70% uptake since 2018.) But we could request or confirm this information at other times instead of annually, and that could have a bearing on "extending" an expiration date automatically. We could also consider other factors, like whether a domain is actually being used on the internet – which is the behavior we want to incentivize, anyway.
Historically (and at launch), the only reason users come to our registrar is to request, set up, and renew their domain. We'll add
manage
to that list soon, changing the dynamic by offering DNS hosting and other supporting services in-registrar.Issue Links
Related to #174
The text was updated successfully, but these errors were encountered: