Rename whitelist -> allow list (#635)

* Rename whitelist -> allow list

* Merge branch 'master' into allowlist-denylist
This commit is contained in:
Ben McIlwain 2020-06-18 18:36:05 -04:00 committed by GitHub
parent f7ca068f8e
commit 23310bd688
91 changed files with 448 additions and 453 deletions

View file

@ -119,7 +119,7 @@ make sense. A master enumeration lists all the valid triplets. They are:
* `AUTH_PUBLIC_OR_INTERNAL`: Allows anyone access, as long as they use OAuth to
authenticate. Also allows access from App Engine task-queue. Note that OAuth
client ID still needs to be whitelisted in the config file for OAuth-based
client ID still needs to be allow-listed in the config file for OAuth-based
authentication to succeed. This is mainly used by the proxy.
### Action setting golden files

View file

@ -137,7 +137,7 @@ used extensively throughout the codebase:
a loop.
* With the `of` method: used when constructing the collection with a
handful of elements. Most commonly used when creating collections
representing constants, like lookup tables or whitelists.
representing constants, like lookup tables or allow lists.
* With the `copyOf` method: used when constructing the method from a
reference to another collection. Used to defensively copy a mutable
collection (like a return value from an external library) to an

View file

@ -350,11 +350,11 @@ An EPP flow that creates a new domain resource.
* Requested domain is reserved.
* Linked resource in pending delete prohibits operation.
* Requested domain requires a claims notice.
* Nameservers are not whitelisted for this TLD.
* Nameservers not specified for domain on TLD with nameserver whitelist.
* Nameservers are not allow-listed for this TLD.
* Nameservers not specified for domain on TLD with nameserver allow list.
* The requested domain name is on the premium price list, and this
registrar has blocked premium registrations.
* Registrant is not whitelisted for this TLD.
* Registrant is not allow-listed for this TLD.
* Requested domain does not require a claims notice.
* 2305
* The allocation token is not valid for this domain.
@ -760,9 +760,9 @@ statuses are updated at once.
clear that status.
* Resource status prohibits this operation.
* Linked resource in pending delete prohibits operation.
* Nameservers are not whitelisted for this TLD.
* Nameservers not specified for domain on TLD with nameserver whitelist.
* Registrant is not whitelisted for this TLD.
* Nameservers are not allow-listed for this TLD.
* Nameservers not specified for domain on TLD with nameserver allow list.
* Registrant is not allow-listed for this TLD.
* 2306
* Cannot add and remove the same value.
* More than one contact for a given role is not allowed.
@ -950,7 +950,7 @@ An EPP flow for login.
* Specified extension is not implemented.
* 2200
* Registrar certificate does not match stored certificate.
* Registrar IP address is not in stored whitelist.
* Registrar IP address is not in stored allow list.
* Registrar certificate not present.
* Registrar password is incorrect.
* Registrar with this client ID could not be found.

View file

@ -71,9 +71,9 @@ label.
## Domain create restriction on closed TLDs
Nomulus offers the ability to "lock-down" a TLD so that domain registration is
forbidden except for whitelisted domain names. This is achieved by setting the
forbidden except for allow-listed domain names. This is achieved by setting the
"domain create restricted" option on the TLD using the `nomulus` tool. Domains
are whitelisted for registration by adding them to reserved lists with entries
are allow-listed for registration by adding them to reserved lists with entries
of type `NAMESERVER_RESTRICTED`. Each domain will thus also need to have
explicitly allowed nameservers configured in its reserved list entry, per the
previous section.
@ -90,7 +90,7 @@ Note that you do **not** have to set a TLD-wide allowed nameservers list with
this option, because it operates independently from the per-domain nameservers
restriction that `NAMESERVER_RESTRICTED` reservation imposes.
In addition to disabling registration of non-whitelisted domains, setting a TLD
In addition to disabling registration of non-allow-listed domains, setting a TLD
as domain create restricted also applies the `SERVER_UPDATE_PROHIBITED` and
`SERVER_TRANSFER_PROHIBITED` statuses to domains upon creation. Any domains on a
domain create restricted TLD are therefore virtually immutable, and must be

View file

@ -28,7 +28,7 @@ certifications required across gTLDs?**
implementation. Here is how we answer it: ]*
The registry does not provide a secure certificate. Registrars must provide
their own certificate during onboarding, which will be whitelisted for the
their own certificate during onboarding, which will be allow-listed for the
connection. A single certificate can be used for multiple TLDs.
**1.4 Locks and statuses: do lock and status rules follow RFC specifications?**
@ -277,7 +277,7 @@ We have a shared registry system for EPP, with a shared namespace across all
supported TLDs. Contacts and hosts are shared across all TLDs; for instance, the
same contact can be used for all of a registrar's domains in the system.
**7.11 If using a DRS, are login credentials, IP whitelisting, etc. configured
**7.11 If using a DRS, are login credentials, IP allow listing, etc. configured
separately or will these be the same for all TLDs in your system?**
These will be the same for all TLDs, because we are a shared registry system.
@ -477,20 +477,20 @@ commands.
## Security
*[ The answers in this section depend on your EPP proxy implementation. These
are the answers that we give, because our EPP proxy has IP whitelists, and
are the answers that we give, because our EPP proxy has IP allow lists, and
requires SSL certificates and SNI. We recommend that other proxy implementations
do likewise. ]*
**9.1 How do I specify the IP addresses that can access your EPP system?**
You will be asked to submit your whitelisted IPs (in CIDR notation) during the
You will be asked to submit your allow-listed IPs (in CIDR notation) during the
onboarding process. After completion of the onboarding process, you can use the
support console to manage the IP whitelist for your production account.
support console to manage the IP allow list for your production account.
**9.2 What SSL certificates will you accept for EPP connections?**
We will accept any SSL certificate. You will be asked to submit your certificate
for whitelisting during the onboarding process. After completion of the
for allow-listing during the onboarding process. After completion of the
onboarding process, you can use the support console to manage the certificate
for your production account.