[CCWG-ACCT] CCWG - Proposed Responses to questions on Draft Bylaws
Seun Ojedeji
seun.ojedeji at gmail.com
Sun Apr 10 19:58:33 UTC 2016
Hi,
I don't think anyone is saying that, the point about whether "root zone" be
included or removed in the mission is within scope of the CCWG and the
discussions has tend towards people providing reasons why it should be
included or not.
However, I understand that it may be looking like a policy discussion. The
discussions so far kind-of confirm for me that we could indeed remove "root
zone" while things can be defined/restricted at policy level (and other
fora where the discussion belongs)
Regards
Sent from my LG G4
Kindly excuse brevity and typos
On 10 Apr 2016 20:31, "avri doria" <avri at acm.org> wrote:
>
> 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
>
> _______________________________________________
> 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/8a9d1948/attachment-0001.html>
More information about the Accountability-Cross-Community
mailing list