Add new reserved domain creation from allocation tokens mechanism

Note that this gets rid of anchor tenant codes in reserved lists (yay!), which
are no longer valid.  They have to come from allocation tokens now.

This removes support for LRP from domain application create flow (that's fine,
we never used it and I'm going to delete all of LRP later).  It also uses
allocation tokens from EPP authcodes as a fallback, for now, but that will be
removed later once we switch fully to the allocation token mechanism.

This doesn't yet allow registration of RESERVED_FOR_SPECIFIC_USE domains using
the allocation token extension; that will come in the next CL.  Ditto for
showing these reserved domains as available on domain checks when the allocation
token is specified.

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209019617
This commit is contained in:
mcilwain 2018-08-16 11:41:34 -07:00 committed by jianglai
parent 782643ce33
commit d2f849ac0f
19 changed files with 184 additions and 346 deletions

View file

@ -23,12 +23,18 @@ a price, it has a reservation type. The valid values for reservation types are:
period by a registrant with a valid claim but it is reserved thereafter.
* **`MISTAKEN_PREMIUM`** - The label is reserved because it was mistakenly put
on a premium list. It may be registered during sunrise by a registrant with
a valid claim but is reserved thereafter.
* **`RESERVED_FOR_ANCHOR_TENANT`** - The label is reserved for the use of an
anchor tenant, and can only be registered by someone sending along the EPP
passcode specified here at time of registration. If a label has different
passcodes in different lists that are applied to the same TLD, an error will
occur.
a valid claim but is reserved thereafter. This is deprecated.
* **RESERVED_FOR_SPECIFIC_USE** - The label is reserved for the use of a
specific registrant, and can only be registered by someone sending along the
allocation token at time of registration. This token is configured on an
`AllocationToken` entity with a matching `domainName`, and is sent by the
registrar using the [allocation token EPP
extension](https://tools.ietf.org/id/draft-ietf-regext-allocation-token-07.html).
* **`RESERVED_FOR_ANCHOR_TENANT`** - Like `RESERVED_FOR_SPECIFIC_USE`, except
for an anchor tenant (i.e. a registrant participating in a [Qualified Launch
Program](https://newgtlds.icann.org/en/announcements-and-media/announcement-10apr14-en)),
meaning that registrations can occur during sunrise ahead of GA, and must be
for a two year term.
* **`NAME_COLLISION`** - The label is reserved because it is on an [ICANN
collision
list](https://www.icann.org/resources/pages/name-collision-2013-12-06-en).
@ -48,17 +54,15 @@ label is reserved due to name collision (with message "Cannot be delegated"). In
general `FULLY_BLOCKED` is by far the most widely used reservation type for
typical TLD use cases.
Here's an example of a small reserved list. Note that
`RESERVED_FOR_ANCHOR_TENANT` has a third entry on the line, being the EPP
passcode required to register the domain (`hunter2` in this case); and that
`NAMESERVER_RESERVED` also has a third entry, a colon separated list of
Here's an example of a small reserved list. Note that the
`NAMESERVER_RESTRICTED` label has a third entry, a colon separated list of
nameservers that the label can be delegated to:
```
reserveddomain,FULLY_BLOCKED
availableinga,ALLOWED_IN_SUNRISE
fourletterword,FULLY_BLOCKED
acmecorp,RESERVED_FOR_ANCHOR_TENANT,hunter2
acmecorp,RESERVED_FOR_ANCHOR_TENANT
internaldomain,NAMESERVER_RESTRICTED,ns1.internal.tld:ns1.internal.tld
```