[CPWG] CCOR

[David Mackey]

Oh, I see. CCOR is the acronym for the newly proposed Cooperative
Corporation of .ORG Registrants.

Sorry for not having an up-to-date "important acronyms" list in my memory.
I thought it was an additional player.

Cheers,
David

On Fri, Jan 10, 2020 at 11:16 AM Nat Cohen <ncohen at telepathy.com> wrote:

> David,
>
> Here are links to some initial coverage.
>
>
> https://www.reuters.com/article/us-internet-domain-sale/internet-nonprofit-leaders-fight-deal-to-sell-control-of-org-domain-idUSKBN1Z62MW
>
>
> https://www.nytimes.com/2020/01/07/technology/dot-org-private-equity-battle.html
>
>
> https://associationsnow.com/2020/01/new-co-op-aims-to-take-over-org-registry-operations/
>
>
> https://www.theverge.com/2020/1/7/21056029/dot-org-icann-chairman-nonprofit-cooperative-ethos-capital
>
> https://www.engadget.com/2020/01/08/internet-pioneers-group-org-domain/
>
> Apparently it is just getting itself organized now, so I'd expect that
> they'll put out more information themselves once they have finalized their
> set up.
>
> Regards,
>
> Nat
>
>
> On Fri, Jan 10, 2020 at 11:07 AM David Mackey <mackey361 at gmail.com> wrote:
>
>> Nat,
>>
>> Do you have a link that provides more information about "CCOR"? It's a
>> pretty generic keyword and my searching on Google hasn't produced relevant
>> results. lol
>>
>> "It would be run by a non-profit, with respect for civil society
>> principles written into its by-laws, with certain funds clearly allocated
>> to support IETF, but otherwise operated at cost." ... sounds like an
>> interesting option if the operating model proves to be a viable.
>>
>> Cheers,
>> David
>>
>>
>>
>> On Fri, Jan 10, 2020 at 9:40 AM Nat Cohen <ncohen at telepathy.com> wrote:
>>
>>> John,
>>>
>>> Thank you for your in-depth contribution to the discussion.  I can't say
>>> that I have fully digested it all, but a couple of points stood out.
>>>
>>> There's a noteworthy contrast between how some ccTLD authorities handle
>>> their responsibilities and how ICANN does.
>>>
>>> ccTLD authorities for France, Australia, India and New Zealand, among
>>> others, have put out tenders to registry service providers for operating
>>> their respective ccTLDs.  As a result of competitive bidding among registry
>>> service providers, the cost of operating the registries have fallen sharply.
>>>
>>> Even though the ccTLD authorities are presumably a branch of the
>>> government, and could directly set prices if they wished, they turn to a
>>> competitive market to set price - thereby getting them out of the price
>>> setting business.
>>>
>>> ICANN in contrast treats Verisign and ISOC not as registry service
>>> providers but as owners of the .com and .org name spaces.  Verisign and
>>> ISOC do not need to compete with other registry service providers to
>>> operate those name spaces.  They are thus free from competitive pressures.
>>>
>>> The $1.35 billion that Ethos Capital is prepared to pay ISOC for .org is
>>> a (low end) valuation of the ongoing harm imposed on registrants due to
>>> ICANN's mismanagement of .org.  If .org was run at cost, there would be no
>>> surplus for Ethos Capital to plunder.  It's an example of the road to hell
>>> being paved with good intentions.  ICANN may have been motivated by good
>>> intentions when it awarded .org as a sinecure to ISOC so that ISOC could
>>> fund its operations by overcharging dot-org registrants.  But now that
>>> power to overcharge .org registrants is worth over a billion dollars, and
>>> now that ISOC wants out, ICANN has created the conditions for a private
>>> equity firm to strip mine the nonprofit community of the charitable
>>> contributions that they rely on to carry out their public service missions.
>>>
>>> If ICANN does not want to be in the business of regulating prices, it
>>> should have let the marketplace do that by putting the .com and .org
>>> registries out for regular rebid.
>>>
>>> That ICANN instead ceded a perpetual right to run the registries to
>>> Verisign and ISOC is clear evidence of just how much under the thumb of the
>>> registries ICANN is.
>>>
>>> Even after granting a perpetual no-bid right to run the registries,
>>> ICANN could still have looked to the current market prices charged by
>>> registry service providers in other competitive bid situations to determine
>>> the market price.  Here again, ICANN would not be a price regulator, they
>>> would merely be applying the price as determined by the market.
>>>
>>> But again ICANN swallowed the self-serving and entirely false position
>>> pushed by the registries and their many lobbyists planted throughout ICANN,
>>> that competition from new gTLDs would serve to constrain prices on .com and
>>> .org.  That has been debunked in depth elsewhere, and I'd be glad to share
>>> the articles with anyone still holding this view.
>>>
>>> ICANN, acting as if it were a parasitic host whose brain had been taken
>>> over by the registries, blindly swallowed the "we are not a price
>>> regulator" and "competition with other gTLDs will hold down prices"
>>> mantras, and lifted all price caps on .org.
>>>
>>> If ICANN had been properly run from the beginning, a group like the
>>> newly formed CCOR would be currently operating .org.  It would be run by a
>>> non-profit, with respect for civil society principles written into its
>>> by-laws, with certain funds clearly allocated to support IETF, but
>>> otherwise operated at cost.
>>>
>>> If this had happened, end users would not have seen hundreds of millions
>>> of dollars that they had contributed to nonprofits over the years,
>>> needlessly diverted to ISOC and PIR where ISOC and PIR adopted a wasteful
>>> approach to this undeserved gusher of funding from controlling .org.
>>>
>>> From an end-user perspective, the choice between having .org controlled
>>> by CCOR, subject to regular rebid, or controlled by Ethos Capital, subject
>>> to resale to who knows what corrupt oligarch, is clear.
>>>
>>> Regards,
>>>
>>> Nat
>>>
>>>
>>>
>>> On Fri, Jan 10, 2020 at 1:59 AM John McCormac <jmcc at hosterstats.com>
>>> wrote:
>>>
>>>> On 07/01/2020 21:03, Jonathan Zuck wrote:
>>>> > Thanks John, your posts are always informative. I know you have some
>>>> > structural issues with the registry/registrar model which has
>>>> > disadvantaged some smaller markets and gTLDs. Do you have specific
>>>>
>>>> The registry/registrar model is affecting the gTLDs at a local hoster
>>>> level in developing markets, Jonathan,
>>>> Basically what is a large hoster in some of these markets is not on the
>>>> same financial level as an ICANN registrar and the logical progression
>>>> isn't from hoster to ICANN registrar but hoster to ccTLD registrar.
>>>> This
>>>> is also seen in the mature/developed markets but for a different
>>>> reason.
>>>> In mature markets outside the USA, the momentum in new registrations is
>>>> almost completely in the ccTLDs and the legacy gTLDs have plateaued.
>>>> There was a good presentation on this from someone from the .ZA
>>>> registry
>>>> on trying to solve this developing markets problem at one of the ICANN
>>>> meetings.
>>>>
>>>> ICANN and its economic reports got the competition angle on new gTLDs
>>>> wrong. There was very little competition between gTLDs and it was
>>>> ICANN's failure to act that created real competition between the gTLDs
>>>> and ccTLDs rather than between gTLDs. People found that they could get
>>>> the domain names they wanted in their local ccTLD. Now, the ccTLDs are
>>>> competing with the gTLDs and largely winning.
>>>>
>>>> People are focused on the size of the total .COM rather than the
>>>> reality
>>>> that it is a composite of a small global market and many country level
>>>> markets where .COM is either plateaued or declining. It is the US
>>>> market
>>>> that is driving .COM and it may be vulnerable to the ccTLD effect. The
>>>> first indications of that in the US market will be a slight drift to
>>>> the
>>>> .US ccTLD. The .COM has been helped in the US market by the sheer
>>>> volume
>>>> of US .COM registrations and the inability of the .US ccTLD registry to
>>>> cope with that scale of a competitor. Its discounting offers have also
>>>> added a boom and bust element to its zone file.
>>>>
>>>> > thoughts on "individual end user" interests in the new .COM contract?
>>>> > What points do you think would be most important for At-Large to
>>>> make.
>>>> > As you say, roundabout ways to dealing with different issues aren't
>>>>
>>>> This needs a lot of thought as ALAC has to choose its battles carefully.
>>>>
>>>> The price increases will have the most impact on end users. The focus
>>>> on
>>>> the impact of price increases on domainers is misleading as domainers
>>>> only represent a small set of .COM domain names.
>>>>
>>>> The more expensive the .COM gets and the stronger the local ccTLDs get,
>>>> the more likely it is that a new registrant will only opt for a ccTLD
>>>> domain name rather than .COM as a primary brand. The .COM has benefited
>>>> from being a "must register" TLD but the price rises will cause
>>>> problems. People at a registrar/ICANN level generally think in
>>>> wholesale
>>>> costs but the .COM price increase will be multiplied by the time it
>>>> gets
>>>> to the end user. This will make the US market increasingly important
>>>> for
>>>> the .COM because it may begin to lose its market share in markets
>>>> outside the US. The historical registrations should be OK for a while
>>>> but it is in the new registrations volume where the effect will appear
>>>> first. The renewal rates are very different on a country level basis.
>>>> The price increases may have a greater impact on countries with weaker
>>>> economies.
>>>>
>>>> Purely from the security and statistics side of things, the amended
>>>> bulk
>>>> access/zone file access section contains the 3 month blackout thing
>>>> where zone file access is limited to three month periods before the
>>>> CZDS
>>>> user has to rerequest access to the zonefile. This was not part of the
>>>> CZDS specification and was added by a person or persons in ICANN who
>>>> were unaware of the damage it would cause to the cybersecurity and
>>>> tracking. It is not an end-user issue but the cybersecurity aspect
>>>> directly impacts end-users. Versign and some of the other legacy gTLDs
>>>> on the CZDS have a more grown-up approach and do not use basic period
>>>> of
>>>> 3 months.
>>>>
>>>> > ideal and price caps to support defensive registrations doesn't seem
>>>> > like the answer to defensive registrations. What would we like to see
>>>> if
>>>>
>>>> A defensive registration can simply be a .COM registration where the
>>>> registrant uses a website in another TLD as their primary brand. Bulk
>>>> defensive registration activity (as in the Citibank example) is more
>>>> easily identified as most of these registrations are hosted on
>>>> specialist registrars and hosters. Ordinary defensive registrations are
>>>> more often .COM/ccTLD pairs. The gTLD domain name is only one part of
>>>> the puzzle.
>>>>
>>>> Strange as it seems, price increases reduce the requirements for
>>>> defensive registrations because it becomes more expensive for a bad
>>>> actor to target brands/IP in bulk. This is why the more expensive new
>>>> gTLDs have lower levels of this kind of DNS abuse.
>>>>
>>>> The other aspect of DNS abuse is that it does not specifically cover
>>>> webspam in its definition. The bulk of abusive registrations in Domain
>>>> Tasting were monetising abusive registrations with PPC rather than
>>>> being
>>>> used for disposable e-mail spam and phishing purposes. Google's
>>>> decision
>>>> to stop monetising registrations less than five days old had a greater
>>>> immediate impact on Domain Tasting than ICANN's initial move.
>>>>
>>>> > this contract goes forward beyond the commitments that have been made
>>>> > already from the new contract and the investment in research and
>>>> > education on SSR? DNS Abuse measures? Trusted notifier stuff like
>>>> Donuts
>>>> > has? What would you like to see given your facility with the numbers?
>>>>
>>>> Verisign has some excellent people working on these issues. The most
>>>> effective way of hitting DNS and web abuse is by limiting the ability
>>>> of
>>>> a registry to discount. The problem is that it will also potentially
>>>> limit the ability of the registry to survive.
>>>>
>>>> Discounting, whether people like it or not, is a legitimate business
>>>> tool for registries and registrars. On the matter of DNS abuse, the
>>>> report from Interisle.net on the matter should be read by everyone with
>>>> an interest in the subject.
>>>>
>>>> The abuse measures are noble aspirations but the reality is that the
>>>> threats change. Much of the the damage and abuse that has been seen
>>>> with
>>>> the highly discounted new gTLDs has largely been self-inflicted by the
>>>> registries. The discounted regisration fee has made some models of DNS
>>>> and web abuse economically viable. The CCT-RT report cited the Dutch
>>>> report on this but the report concentrated mainly on reported
>>>> incidents.
>>>> This is a major shortcoming with dealing with DNS abuse as it relies on
>>>> reporting rather than detection. If it is not detected, then it might
>>>> not as well exist to ICANN and the registry but the end-user is going
>>>> to
>>>> suffer anyway. It can also be poisoned by incorrect data. One of the
>>>> most famous incidents was where the .ZIP was designated the most toxic
>>>> of the new gTLDs by some security consultancy. The .ZIP gTLD wasn't
>>>> even
>>>> active. (That was a wonderful example of the weakness of ICANN's
>>>> evaluation process in allowing a commonly used file extension to become
>>>> a gTLD. Ironically .com was a file extension dating back to the 1970s.)
>>>>
>>>> One of the metrics in the web usage reports that I run is a compromised
>>>> sites estimate per TLD. That is partially based on a continually
>>>> updated
>>>> "toxic links" table of URLs that are known to be used in link
>>>> injections
>>>> and links that should not appear in certain sets of websites. Basically
>>>> these are links for discounted gTLDs that appear in gTLDs/ccTLDs where
>>>> there's no real connection and they appear identically across a set of
>>>> sites. Some of the historical survey data here goes back over ten years
>>>> or so. It is not unusual to see compromised websites remain compromised
>>>> for years.
>>>>
>>>> Unfortunately the definition of DNS abuse is too narrow to encapsulate
>>>> such issues because it is purely focused on DNS, reported phishing,
>>>> malware, botnet and e-mail spam. Web-side abuse is far worse in some
>>>> respects as it kills gTLDs. The .LOAN gTLD's business model looked good
>>>> initially but it collapsed (around 2015 or so) and the then registry
>>>> manager, Famous Four Media, turned to discounting as a means to inflate
>>>> the zone. The problem was that it ended up with approximately a million
>>>> or so adult and gambling affiliate websites and only a few hundred
>>>> on-topic websites. Most of those affiliate sites washed out of the zone
>>>> when the new registry management made the decision to increase the
>>>> wholesale renewal/registration fee in August 2018. Pricing, ironically,
>>>> is the most effective tool in fighting some forms of DNS abuse.
>>>>
>>>> Most of these link injection compromises are easily detected and could
>>>> be detected in a TLD-wide scan by Verisign. The reality is that the
>>>> number of websites that would need to be scanned is far smaller than
>>>> the
>>>> total number of .COM registrations. It would be relatively easy for
>>>> Verisign, should it decide to go down this path, to implement a system
>>>> where it could notify registrars of such issues. The problem arises
>>>> where these registrars then have to notify resellers/hosters who would
>>>> then have to notify their customers. There's also the possibility that
>>>> the customer has outsourced the development of the site that was
>>>> compromised so there are many links in the kill chain to securing a
>>>> compromised site.
>>>>
>>>> The .COM, by virtue of being the largest TLD, will see more compromised
>>>> sites than other TLDs. But the pricing issue reduces the volume of
>>>> webspam because the discounted gTLDs are more economically viable.
>>>>
>>>> The Public Interest Commitments (Section a) requires the
>>>> registrar-registrant agreement to have terms forbidding phrarming,
>>>> malware distribution, botnet operations and, most interestingly
>>>> copyright infringement and counterfeiting. The problem with the last
>>>> two
>>>> issues is that Section b (where the registry will run surveys of the
>>>> TLD
>>>> to measure security threats) makes no reference to them as being part
>>>> of
>>>> the security threat model. With copyright infringement, apart from the
>>>> obvious streaming of movies and Pay TV programming, it can be a very
>>>> difficult task to identify the original copyright owner. Some of the
>>>> Chinese software used to produce such sites is quite sophisticated in
>>>> how it scrapes websites, blogs and search engine results. It can be an
>>>> absolute nightmare, at times, writing the code to distinguish between a
>>>> legitimate website and one of these generated websites.
>>>>
>>>> With streaming services, there are two basic types. The first,
>>>> obviously, are the services that stream content in real time. They are
>>>> high bandwidth operations. The second are the services that just
>>>> redistribute the keys from a legitimately subscribed smartcard so that
>>>> a
>>>> set of decoders connected by the Internet can all just a single
>>>> smartcard to access programming. That kind of service is more difficult
>>>> for a registry to identify as it is relatively sparse data and those
>>>> networks tend to be relatively small in size. Trying to detect these
>>>> services is a waste of the registry's time and resources. Websites
>>>> offering streaming services will be picked up in Verisign's monthly
>>>> scan.
>>>>
>>>> There's a break between Section a and Section b of the PICs in that
>>>> there's no requirement for the registry to take any action. It is only
>>>> required to record any action that it does take. The registrar is the
>>>> one in the firing line as section a specifically mentions the registrar
>>>> having terms in its contract with the registrant.
>>>>
>>>> Regards...jmcc
>>>> --
>>>> **********************************************************
>>>> John McCormac  *  e-mail: jmcc at hosterstats.com
>>>> MC2            *  web: http://www.hosterstats.com/
>>>> 22 Viewmount   *  Domain Registrations Statistics
>>>> Waterford      *  Domnomics - the business of domain names
>>>> Ireland        *  https://amzn.to/2OPtEIO
>>>> IE             *  Skype: hosterstats.com
>>>> **********************************************************
>>>> _______________________________________________
>>>> CPWG mailing list
>>>> CPWG at icann.org
>>>> https://mm.icann.org/mailman/listinfo/cpwg
>>>>
>>>> _______________________________________________
>>>> By submitting your personal data, you consent to the processing of your
>>>> personal data for purposes of subscribing to this mailing list accordance
>>>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy)
>>>> and the website Terms of Service (https://www.icann.org/privacy/tos).
>>>> You can visit the Mailman link above to change your membership status or
>>>> configuration, including unsubscribing, setting digest-style delivery or
>>>> disabling delivery altogether (e.g., for a vacation), and so on.
>>>>
>>> _______________________________________________
>>> CPWG mailing list
>>> CPWG at icann.org
>>> https://mm.icann.org/mailman/listinfo/cpwg
>>>
>>> _______________________________________________
>>> By submitting your personal data, you consent to the processing of your
>>> personal data for purposes of subscribing to this mailing list accordance
>>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy)
>>> and the website Terms of Service (https://www.icann.org/privacy/tos).
>>> You can visit the Mailman link above to change your membership status or
>>> configuration, including unsubscribing, setting digest-style delivery or
>>> disabling delivery altogether (e.g., for a vacation), and so on.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cpwg/attachments/20200110/a1c81d7e/attachment-0001.html>