Hi Andrew, Thanks for providing convincing explanation to confirm there is indeed a way to approach this (based on ICANN policy authority on the root). That said, I like to quote a specific part of your message below which I think may be quite important. "...If there is language needed to make it clear that such contractual terms required for deletation are ok (and I do not believe there is such a need, but let's suppose it), then the language must be about that. It must not weaken the claim that ICANN's proper DNS mission is with respect to the root zone and not others...." Considering that staff has implementation experience on this, it may be good hear their thought on the first part of your comment above. Hopefully we will not be taking the question to legal (well maybe we could ask ICANN staff legal since they are expected to have some implementation experience as well). Regards Sent from my LG G4 Kindly excuse brevity and typos On 11 Apr 2016 03:28, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
On Sun, Apr 10, 2016 at 06:40:46PM +0100, Seun Ojedeji wrote:
above. A layman thought is a scenario where there is a rule by ICANN that requires gTLDs to consider icann.tld to be forbidden, so if removing the "in the root" can permit that legitimately then I would be fine.
SO: I agree and this bothers me as well. If there is other way to do this without going out of the scope then it will be good otherwise, I think this change should be clearly marked during the PC with our rationale indicated.
Apparently I have still failed to communicate this clearly enough: there is a way to do that. It stems from ICANN's control of delegations from the root zone.
Every delegation in the root involves delegation to another party. Those parties are TLD registries.
When ICANN delegates to a registry, it can attach conditions to that delegation. And in fact, that's what it does today: when an entity (organization, corporation, individual, whatever) gets a delegation from the root, it agrees to all sorts of consensus policies. The key thing here is that it is the _entity_ that makes the agreement. That agreement often imposes terms on the operation of the delegated name space.
These are terms that control the actions of the entity -- it's not about "levels" in the DNS. So, ICANN can also control the actions of the entity lower in the tree, or even elsewhere in the tree (this sort of term, for instance, is what made it possible for ICANN to require registries not to be registrars -- it's not regulation, but commercial agreement. I won't agree to X unless you agree to Y). It all stems from ICANN's policy control over the root zone. If there is language needed to make it clear that such contractual terms required for deletation are ok (and I do not believe there is such a need, but let's suppose it), then the language must be about that. It must not weaken the claim that ICANN's proper DNS mission is with respect to the root zone and not others.
This sort of term allows for ICANN's ability to impose conditions on contracted parties anywhere in the DNS name space at all, without specifying what ICANN can do at this or that "level" of the DNS. In DNS terms, the "levels" of the DNS are a figment of the imagination. There's no technical difference between name deletation from really.dumb.long.name.anvilwalrusden.com and com itself. There's a _legal_ difference, though, and that's the parties to the agreement. I registered anvilwalrusden.com with Verisign through a reseller that resells Tucows services. I have an agreement with the reseller. The reseller has an agreement with Tucows. Tucows has an agreement with ICANN and also with Verisign, and Verisign has an agreement with ICANN too. I don't have an agreement with ICANN, so ICANN can't impose contractual terms on me except indirectly (via a long chain).
I hope this makes clear why ICANN doesn't need to have control over assignment or allocation of names in the DNS generally in order to impose limits on the freedom of TLD registries even outside the name directly deleted. It only needs to work on the root.[1]
A
[1] Again, int is a special case, and I hope we can treat it as the exception it is. I can provide a more complicated account if need be.
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community