RE: [dssa] hm. does anybody have an authoritative source for the definition of "core registry functions"?

[Greg Aaron <gaaron@xxxxxxxxxxxx>]

Dear Mikey and friends:

Regarding new TLDs, see also the ICANN registry agreement paragraph 2.13,
referring to Specification 10 section 6.  The latter lists:
* DNS
* "DNSSEC proper resolution" (which I'd say is a subset of DNS service.
As I noted before, the reality is many ccTLDs don't offer DNSSEC, and few
gTLDs offer signing of individual domains right now.)
* EPP (But that's a specific protocol, and not in use in many ccTLDs; the
real function, more generally stated, is provisioning the registry with
data)
* WHOIS (a.k.a. dissemination of contact and other data), and
* data escrow (however, many ccTLDs don't escrow).

So I keep going back to this definition, which applies to all current and
future gTLDs, and maybe we can agree it's a good list for ccTLDs too:

"the receipt of data from registrars concerning registrations of domain
names and name servers; provision to registrars of status information
relating to the zone servers for  the TLD; dissemination of TLD zone
files; operation of the registry zone servers; and dissemination of
contact and other information  concerning domain name server registrations
in the TLD as required by the Registry Agreement".

All best,
--Greg


-----Original Message-----
From: Greg Aaron [mailto:gaaron@xxxxxxxxxxxx]
Sent: Thursday, January 12, 2012 10:24 AM
To: 'Mike O'Connor'; 'dssa@xxxxxxxxx'
Subject: RE: [dssa] hm. does anybody have an authoritative source for the
definition of "core registry functions"?

Hey, Mikey:

No.  Zone File Access and Bulk Registration Data Access are required in
nTLD contacts, but might not be considered critical registry functions.

"Zone file access" is not the same as publishing the zone files on the TLD
servers.  Zone file access is making the zone file available for download
by anyone who wants it.  See the gTLD contracts and Zone File Access
Agreements for details.   Most ccTLDs don't offer zone file access.

"Bulk Registration Data Access" is an ICANN nTLD contract term.  It is
something different from regular-old WHOIS, and it's actually different
from escrow.  Most existing gTLDs and most ccTLDs don't offer bulk WHOIS.
I did a quick check (and Patrick or someone correct me if I have missed
it), but most existing gTLDs don't seem to have the term "Bulk
Registration Data Access" in their contracts.

Note that registry provisioning IS considered a critical function as per
the ICANN contractual definition.  Provisioning = "the receipt of data
from registrars concerning registrations of domain names and name
servers".

I think part of the confusion comes when one tries to link registry
continuity (a formal effort spurred by the nTLD program) with critical
functions.  In order to transition a registry, one must accomplish many.
many tasks.  However, not all of those are minimal base functions, and you
have to concentrate on the ones that are absolutely required in order to
keep the registry functioning.   Things like ZFA are not critical. I keep
going back to the ICANN contract definition as a statement of principles
of what's essential to keep a registry functioning at the basic level.

All best,
--Greg




-----Original Message-----
From: Mike O'Connor [mailto:mike@xxxxxxxxxx]
Sent: Thursday, January 12, 2012 8:28 AM
To: dssa@xxxxxxxxx
Subject: Re: [dssa] hm. does anybody have an authoritative source for the
definition of "core registry functions"?


Cloud Registry just refined their model a bit in this post --
http://www.circleid.com/posts/facets_of_gtld_registry_technical_operations
_registry_services/

they make the distinction between

        - Provisioning -- EPP, Policies, IDN rules, DNSSEC signing

        - Publication -- DNS, WHOIS, Zone File Access, Bulk Registration
Data Access

based on our conversation so far, it seems like we're leaning towards the
"Publication" side of their model, no?

mikey


On Jan 11, 2012, at 12:30 PM, Greg Aaron wrote:

>
> Hi, Mikey.  Cloud Registry seems to be mainly talking to new TLD
> applicants who want to comply with ICANN's new TLD contractual
> requirements.  Which are not all "critical functions," of course.
Cloud
> Registry's list kind of reinvents the wheel, and is not a great fit
> for our work because:
> * EPP is not a "critical function."  Accepting and storing data is a
> critical function.  EPP is a protocol for transmitting data.
> * See my notes below regarding DNSSEC.
> * IDN is no "critical" registry function, because you can run a
> registry quite well without offering IDNs.  For example, .AU does not
offers IDNs.
> Yet somehow, .AU perseveres.  ;-)
>
> All best,
> --Greg
>
>
> -----Original Message-----
> From: Mike O'Connor [mailto:mike@xxxxxxxxxx]
> Sent: Wednesday, January 11, 2012 8:51 AM
> To: dssa@xxxxxxxxx
> Subject: Re: [dssa] hm. does anybody have an authoritative source for
> the definition of "core registry functions"?
>
>
> so in a recent blog post, the Cloud Registry folks quoted that same
> section of the Guidebook and then summarized the list thusly;
>
> EPP, DNS, Whois, IDN and DNSSEC
>
> how do people feel about that list of services?
>
> if i were a stratifying kinda guy, i might say that DNS is one kind of
> thing ("the DNS") and EPP, WHOIS, IDN and DNSSEC are another kind of
> thing (services that support "the DNS" but not actually part of it).
> so from our charter, are those other things "in scope" for our review?
>
> i'm posing this partly from the project-manager point of view (trying
> to manage scope) and partly from a technical/architecture/boundaries
> point of view.  it seems to me that "the DNS" could run without any of
> those other services.  and attacks against those other things, while
> causing a lot of pain, wouldn't take down "the DNS"
>
> discuss.  ;-)
>
> mikey
>
> btw, here's a link to their post --
> http://www.cloudregistry.net/blog/e/gtld-registry-services/
>
>
> On Jan 9, 2012, at 10:04 AM, Greg Aaron wrote:
>
>>
>> Please see the legal definition in the nTLD contract (Specification
>> 6, #2), which was taken from and is the same definition as for
>> existing gTLDs (see "core registry services" on the RSEP page at:
>> http://www.icann.org/en/registries/rsep/rsep.html ).  That's the
>> definition relevant to both existing and new gTLDs.
>>
>> That definition says that critical registry services are those:
>> "critical to the following tasks: the receipt of data from registrars
>> concerning registrations of domain names and name servers; provision
>> to registrars of status information relating to the zone servers for
>> the TLD; dissemination of TLD zone files; operation of the registry
>> zone servers; and dissemination of contact and other information
>> concerning domain name server registrations in the TLD as required by
> the Registry Agreement".
>>
>> New gTLDs will be contractually required to have DNSSEC, but existing
>> gTLDs are not required to have DNSSEC.  Many ccTLDs have not signed
>> their zones, and many ccTLDs and gTLDs who have signed their zones
>> still don't allow registrants to sign individual domains.  It is
>> highly desirable for registries to provide DNSSEC, and when they do
>> it's important to do it correctly.  But because of the above reasons
>> it may not be possible to say that DNSSEC is a "critical" registry
> function.
>>
>> Escrow's an important thing, but it doesn't seem to fall under the
>> above definition.  (The clause "dissemination of contact and other
>> information concerning domain name server registrations" is about
>> WHOIS, I believe.) Note that some, maybe many, ccTLDs don't escrow.
>> Hopefully all make off-site backups and observe other prudent
>> practices, but perhaps few do it like ICANN requires, which mandates
>> the use of third-party independent escrow providers.
>>
>> All best,
>> --Greg
>>
>>
>>
>> -----Original Message-----
>> From: Drazek, Keith [mailto:kdrazek@xxxxxxxxxxxx]
>> Sent: Sunday, January 08, 2012 12:53 PM
>> To: dssa@xxxxxxxxx
>> Subject: RE: [dssa] hm. does anybody have an authoritative source for
>> the definition of "core registry functions"?
>>
>>
>>
>> Hi Mikey,
>>
>> The phrase now used by ICANN is "critical registry functions," which
>> has been defined most recently through the new gTLD application
>> process. The definition is in several places in the Applicant
>> Guidebook, including in the section covering the Continued Operations
> Instrument.
>>
>> http://www.icann.org/en/registries/continuity/gtld-registry-continuit
>> y
>> -pla
>> n-25apr09-en.pdf
>>
>>
>> Earlier definitions had a slightly longer lists of six or more:
>>
>> http://www.icann.org/en/registries/reports/registry-failover-01jun07.
>> h
>> tm#a
>> nchor3 (see Section 3 of the 2007 Registry Failover Report)
>>
>> http://www.icann.org/en/registries/continuity/gtld-registry-continuit
>> y -pla n-25apr09-en.pdf (see page 4 of the 2009 Registry Continuity
>> Plan)
>>
>>
>> Hope this helps.
>>
>> Regards, Keith
>>
>>
>>
>>
>> Keith Drazek
>> Director of Policy
>> kdrazek@xxxxxxxxxxxx
>>
>> m: +1-571-377-9182
>> 21345 Ridgetop Circle Dulles, VA 20166
>>
>> VerisignInc.com
>>
>>
>>
>> -----Original Message-----
>> From: owner-dssa@xxxxxxxxx [mailto:owner-dssa@xxxxxxxxx] On Behalf Of
>> Mike O'Connor
>> Sent: Sunday, January 08, 2012 9:20 AM
>> To: dssa@xxxxxxxxx
>> Subject: [dssa] hm. does anybody have an authoritative source for the
>> definition of "core registry functions"?
>>
>>
>> hi all,
>>
>> i came across the "core registry functions" phrase and thought that
>> might be a good list for us to have.  here's the quote that got me
>> started
>>
>>      "Core registry functions are: access to the shared registry
> system;
>> Whois, DNS resolution; data escrow; and DNSSEC"
>>
>> the list looks like a good scope-defining punch-list for some of our
> work.
>>
>> but this is from a Minds and Machines advocacy piece on CircleID and
>> is by no means authoritative.  are they quoting an RFC or something
>> that *is* authoritative?  if so, could you point me in the right
> direction?
>>
>> thanks,
>>
>> mikey
>>
>> - - - - - - - - -
>> phone        651-647-6109
>> fax                  866-280-2356
>> web  http://www.haven2.com
>> handle       OConnorStP (ID for public places like Twitter, Facebook,
> Google,
>> etc.)
>
> - - - - - - - - -
> phone         651-647-6109
> fax           866-280-2356
> web   http://www.haven2.com
> handle        OConnorStP (ID for public places like Twitter, Facebook,
Google,
> etc.)

- - - - - - - - -
phone   651-647-6109
fax             866-280-2356
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google,
etc.)