I believe that putting together a static list of something that is not
clearly defined when there is no clear policy for adding/removing
items from the list and no clear authority defined to execute the
policy and responsible to keep the list updated will make the list
useless on day D-1.
Which is why I think setting up an IANA registry makes sense: the
setting up of the registry forces one to define all of that too.
I see your point. We also need to remember that some names are based
on rules and not static strings.
I believe there is some work related to EPP about how
registrars/registries exchange info about reserved names but I don't
recall the specifics right now.
AFAIK there is no definition of "reserved names" in any of the EPP
specifications. Are you referring to some other forum other than the
IETF?
Didn't cross reference with any drafts or ietf-wg mailing lists, but
the text of the proposed new registry agreement says (page 197 of
DAGv3):
<quote>
4.5 Object Statuses. RFC 4930 (EPP) and related RFCs, see [1], [2],
[3], [4] indicate permissible status
codes for various registry objects. Additionally the status “reserved”
is allowed for domains; it is used
to indicate a reserved name on behalf of the Registry or ICANN.
4.6 Reserved Name Handling. Registries typically have a set of names
reserved on behalf of themselves
or IANA. Reserved names must be included in the DOMAIN file, and have
the special "reserved"
status associated with them in the DOMSTATUS file to indicate that
they are reserved.
</quote>
For the references 1,2,3,4 the doc says:
<quote>
[1] Extensible Provisioning Protocol (EPP),
http://www.rfc-editor.org/rfc/rfc4930.txt
[2] EPP Domain Name Mapping, http://www.rfc-editor.org/rfc/rfc4931.txt
[3] EPP Host Mapping, http://www.rfc-editor.org/rfc/rfc4932.txt
[4] EPP Contact Mapping, http://www.rfc-editor.org/rfc/rfc4933.txt
</quote>
Jorge
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf