[CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
avri doria
avri at acm.org
Sun Apr 10 19:12:02 UTC 2016
Exactly.
This aspirational goal some may have to control the content of the
entire name tree is not a fit topic for this list.
thank you Marilyn.
avri
On 10-Apr-16 15:21, Marilyn Cade wrote:
> Sorry to ask but is this actually a suitable discussion for CCWG
> Accountability?
>
> I need to focus on the actual work of this CCWG and I find other
> postings diverting.
>
>
>
> ------------------------------------------------------------------------
> Date: Sun, 10 Apr 2016 14:14:50 -0400
> From: gregshatanipc at gmail.com
> To: avri at acm.org
> CC: accountability-cross-community at icann.org
> Subject: Re: [CCWG-ACCT] CCWG - Proposed Responses to questions on
> Draft Bylaws
>
> The third level can function (or be marketed) just like the second
> level. Look at <example>.uk.com <http://uk.com> or <example>.co.no
> <http://co.no>, for example. I believe a number of the new gTLDs
> offer or intend to offer or enable others to offer registrations at
> the third level, in many of these cases keeping the second level label
> within the registry (or an affiliate). That's one of the reasons we
> are seeing requests for country and territory names/codes to be
> allowed at the second level. It would be incorrect to assume that all
> third level labels are owned and managed by the owner of the second
> level domain. A policy based on that assumption would be likewise
> incorrect.
>
> Greg
>
>
>
> 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
> <mailto:gshatan%20 at mccarter.com> | www.mccarter.com
> <http://www.mccarter.com/>
>
> BOSTON | HARTFORD | STAMFORD | NEW YORK | NEWARK
> EAST BRUNSWICK | PHILADELPHIA | WILMINGTON | WASHINGTON, DC
>
>
>
>
> On Sun, Apr 10, 2016 at 1:42 PM, avri doria <avri at acm.org
> <mailto:avri at acm.org>> 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 <http://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
> <http://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>
> > <mailto: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
> <http://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>
> >>> <mailto: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>
> >>>> <mailto: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>
> >>>>> <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>
> >>>>> <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>
> <mailto:ajs at anvilwalrusden.com <mailto:ajs at anvilwalrusden.com>>
> >>>>> _______________________________________________
> >>>>> 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
> <mailto:Accountability-Cross-Community at icann.org>
> >>>> <mailto: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
> <mailto: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
> <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
More information about the Accountability-Cross-Community
mailing list