[CPWG] CCOR

[David Mackey]

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/99e48a1d/attachment-0001.html>