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

Mon Apr 11 02:16:27 UTC 2016

Alan,

Isn't the flip-side of this to ensure that the Bylaws allow the development
of policies that govern it?

Greg

[image: http://hilweb1/images/signature.jpg]

*Gregory S. Shatan | Partner*McCARTER & ENGLISH, LLP

245 Park Avenue, 27th Floor | New York, New York 10167
T: 212-609-6873
F: 212-416-7613
gshatan @mccarter.com | www.mccarter.com

BOSTON | HARTFORD | STAMFORD | NEW YORK | NEWARK
EAST BRUNSWICK | PHILADELPHIA  | WILMINGTON | WASHINGTON, DC

On Sun, Apr 10, 2016 at 2:58 PM, Alan Greenberg <alan.greenberg at mcgill.ca>
wrote:

> It is not content for SOME TLDs. In those cases, registrants apply for and
> get third level names and ICANN and registrars get paid for names at those
> levels. The Bylaws must sanction this. As Andrew has pointed out, this is
> contractual matter and only applies to selected TLDs, but we need to ensure
> that the Bylaws do not prohibit it.
>
> Alan
>
>
> At 10/04/2016 01:42 PM, avri doria wrote:
>
>> Hi,
>>
>> I do not think this comes up to the level of reduction.
>>
>> The idea that ICANN could tell me what I should or not create at the
>> third level of m17m.org is unreasonable.
>>
>> The transition is no time to create new content powers for ICANN.
>> And the third level is most definitely a content level in m opinion.
>>
>> avri
>>
>> On 10-Apr-16 13:40, Christopher Wilkinson wrote:
>> > > some.stupid.label.anvilwalrusden.com
>> >
>> > Hmmm … I suggest that it is not very helpful to try and deny common
>> > sense through a /reductio ad absurdum./
>> >
>> > CW
>> >
>> >
>> > On 10 Apr 2016, at 18:34, Andrew Sullivan <ajs at anvilwalrusden.com
>> > <mailto: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.
>> >>
>> >> Moreover, this retreat by the CCWG is not consistent with the
>> >> approved document.  The bylaw text and the CCWG proposal are
>> >> substantively different.
>> >>
>> >> A
>> >>
>> >> --
>> >> Andrew Sullivan
>> >> Please excuse my clumbsy thums.
>> >>
>> >>> On Apr 9, 2016, at 13:44, Christopher Wilkinson
>> >>> <lists at christopherwilkinson.eu
>> >>> <mailto: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
>> >>>> <mailto: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
>> >>>>> <http://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
>> >>>>> <http://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 <mailto: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
>> >>>> <mailto: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
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>> 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/e1883bbf/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6549 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160410/e1883bbf/image001-0001.jpg>