[CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws

Sun Apr 10 17:40:46 UTC 2016

Sent from my LG G4
Kindly excuse brevity and typos
On 10 Apr 2016 17:35, "Andrew Sullivan" <ajs at anvilwalrusden.com> wrote:
>
> If the CCWG's current position stands, then there is no reason that ICANN
cannot make rules at parts of the tree for which it has no responsibility.
It could make a rule requiring me to add
some.stupid.label.anvilwalrusden.com, and there would be no reason in
principle that it didn't have that authority.  But it does not.
>
SO:  If this were possible (in practice) then I will indeed see no problem
with adding the restriction. However, there is a chance that adding the "in
the root" could indeed validate claims that ICANN cannot make such rules as
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. Or a
scenario where ICANN bans a Registrar/registry and then decide to transfer
the domains to another Registrar/registry which will sure involve engaging
lower layer names.

> Moreover, this retreat by the CCWG is not consistent with the approved
document.  The bylaw text and the CCWG proposal are substantively different.
>

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.

Regards
> A
>
> --
> Andrew Sullivan
> Please excuse my clumbsy thums.
>
> > On Apr 9, 2016, at 13:44, Christopher Wilkinson <
lists at christopherwilkinson.eu> wrote:
> >
> > Good morning:
> >
> > I prefer Alan's first option which was the conclusion that I thought
had been reached at the last CCWG call.
> >
> > i gather that there are still a few participants who consider that the
mission statement should exclude any ICANN responsibility for rules on
higher level names.
> > May I say that should that have been the case at the time, I very much
doubt that ICANN would have been created in its present form.
> >
> > Regards
> >
> > CW
> >
> >
> >> On 09 Apr 2016, at 03:38, Alan Greenberg <alan.greenberg at mcgill.ca>
wrote:
> >>
> >> Andrew, That is a carefully thought out discussion about why we should
not eliminate the "in the root zone" in the general context, but the issue
remains that ICANN DOES have authority to impose rules on higher levels for
gTLDs. So we either need to leave the general mission statement without the
restriction, or add somewhere else that with respect to gTLDs, it is within
its mission to impose rules on higher level names.
> >>
> >> Alan
> >>
> >> At 08/04/2016 08:41 PM, Andrew Sullivan wrote:
> >>
> >>> I think the above demands very careful attention to the reasoning.  I
> >>> believe that, if we consider the above argument, there are two
> >>> possibilities:
> >>>
> >>>  1.  ICANN can do this due to its commercial relationships flowing
> >>>  from its control of the root zone.
> >>>
> >>>  2.  ICANN can do this because it really is in charge overall of
> >>>  names in the DNS.
> >>>
> >>> Let me start with the latter.  I believe that, if that is true, then
> >>> ICANN and anyone who uses the present IANA root servers are complicit
> >>> in undermining the architecture of the DNS.  The design of the DNS is
> >>> decentralized authority.  Indeed, the "SOA" record, which marks the
> >>> apex of every zone in the DNS, stands for "start of authority".  The
> >>> point of this arrangement is to permit distributed management of the
> >>> names in the DNS in accordance with the operational distribution of
> >>> most of the Internet: your network, your rules.  I do not believe for
> >>> a moment that we are all -- or even that ICANN is -- involved in some
> >>> conspiracy to undermine the Internet.  So this explanation makes no
> >>> sense, and therefore the reason for ICANN's ability to set rules about
> >>> registration at parts of the domain name tree must come from something
> >>> else.
> >>>
> >>> That something else is the first option.  ICANN has the policy
> >>> authority over what labels go into the root zone.  ICANN does this by
> >>> coming to some agreement with those who are allocated these labels.
> >>> Those who are allocated such labels may choose to have them activated
> >>> by having them appear in the root zone, in which case the label
> >>> becomes a "top-level domain name", by getting a delegation (some NS
> >>> records in the root zone) to another name server.  At that name
> >>> server, there is an SOA record that marks the start of authority.  So,
> >>> TLD operators after such a delegation are authoritative over the name
> >>> space so delegated.  So, then, how does ICANN get policy authority?
> >>> Simple: commercial agreement.
> >>>
> >>> Since ICANN holds the policy over the root zone, it can in theory
> >>> remove the delegation of the name in question at any time.  So, it can
> >>> set as conditions of its delegation of a name any policies it wants on
> >>> the entity that gets that delegation.  What ICANN does in fact is use
> >>> ICANN-community-developed consensus policies and imposes them on these
> >>> operators.  The condition, then, is on the _operator_, and not on the
> >>> top-level domain as such.  If the operator wants to operate some lower
> >>> domain as a delegation-centric domain [*], then it's not too
> >>> surprising that ICANN believes its agreements cover that too.  And
> >>> hence ICANN's ability to impose terms on registrars: it can require
> >>> TLD registries to permit retail operation only through accredited
> >>> registrars, and then it can set conditions on how that accreditation
> >>> is maintained.  This is ICANN's market-making activity, but it is able
> >>> to do it only through its control of the root zone.
> >>>
> >>> [* Aside: that's what we DNS geeks call TLDs and similar kinds of
> >>> domains: delegation-centric, because they mostly contain delegations.
> >>> Other zones have mostly resource records that point to service
> >>> offerings and so on, like AAAA and A and MX records.  Com is
> >>> delegation-centric because it mostly exists to delegate out to others;
> >>> Verisign doesn't run anvilwalrusden.com any more than ICANN runs com.]
> >>>
> >>> I claim that the above is the reason ICANN's Mission involving
> >>> allocation and assignment of domain names is only in the root. [+] It
> >>> doesn't assign things generally in the DNS.  I am not a direct
> >>> customer of ICANN and I do not have a direct commercial relationship
> >>> with them.  If they told me to register icann.anvilwalrusden.com in my
> >>> zone, I would quite correctly tell them about a short pier awaiting
> >>> their long walk.  Indeed, avoiding such a power (which nobody,
> >>> including I think ICANN, really wants ICANN to have) is precisely what
> >>> the clarifications to ICANN's limited mission is all about.  It
> >>> would be bad for ICANN to have a Mission that gave it overall
> >>> authority over names in the DNS, because that would allow it to be
> >>> used as a regulator.  And indeed, with the new community powers, it
> >>> would be possible for the Empowered Community to force ICANN to act
> >>> that way unless the explicit restriction (to the root zone) is
> >>> restored to the bylaws.
> >>>
> >>> [+ Aside: "only in the root" is a slight exaggeration, because of int.
> >>> But as we all know, int is a bit of a wart on the arrangements and it
> >>> would probably be better if ICANN were out of that.  The only reason
> >>> it hangs around is because of the misfortune that it's already there;
> >>> it isn't clear how to fix it, and we have a different political hot
> >>> potato to cool just now so it'll have to wait.  It's permissable
> >>> anyway under the new bylaws, AFAICT, because the bylaws encourage such
> >>> temporary arrangements in order to support security and stability of
> >>> the DNS.]
> >>>
> >>> Best regards,
> >>>
> >>> A
> >>>
> >>> --
> >>> Andrew Sullivan
> >>> ajs at anvilwalrusden.com
> >>> _______________________________________________
> >>> Accountability-Cross-Community mailing list
> >>> Accountability-Cross-Community at icann.org
> >>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
> >>
> >> _______________________________________________
> >> Accountability-Cross-Community mailing list
> >> Accountability-Cross-Community at icann.org
> >> https://mm.icann.org/mailman/listinfo/accountability-cross-community
> >
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160410/66786989/attachment.html>