>> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf