To:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
cc:
"Paul M. Kane" <Paul.Kane@REACTO.com>, ietf-provreg@cafax.se, "Hollenbeck, Scott" <shollenbeck@verisign.com>, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Thu, 27 Sep 2001 11:23:46 -0400
In-Reply-To:
Your message of "Thu, 27 Sep 2001 09:49:01 EDT." <200109271349.f8RDn1c00719@nic-naa.net>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: "opt-in" schema
The dan.ca <check> against the .com registry example ... Distinct namespaces, see also inextant registries, e.g., name.non-iso3166-ccTLD-2LA or name.not-in-icann-g-or-sTLD-set or name.alternate-root-registry-name-same-as-icann-root-registry-name (e.g., Ms. Gallagos' .biz in the ARNI root) or name.<null> Not to flog a dead horse unduly, but as registries can't initiate instances of communication (absent a pending non-MUST <push> extension), how registry A could acquire state from registry B is ... undefined. Earlier, Stuart suggested that the semantics of <check> may be conditional. He suggested registrant eligibility, but could also have suggested registrar access. In a non-flat namespace, with sub-registries, registrar access may be namespace locality dependant. In the NeuLevel proposal to the US DoC, it was proposed to operate the existing "legacy" locality-based namespace and a new non-locality-based namespace with distinct policies, and in the locality portion of the namespace, to possibly restrict registrar access to delegated 2LD and sub-delegated registries. Thus, an object (name) could "exist" (from the registry's PoV), and the semantics available to the registrant performing <check> not allow write access, or possibly even read access. Eric