ICANN ICANN Email List Archives

[dssa]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Subject: Re: [dssa] hm. does anybody have an authoritative source for the definition of "core registry functions"?
  • From: Jörg Schweiger <schweiger@xxxxxxxx>
  • Date: Thu, 12 Jan 2012 18:24:51 +0100

> Von: "Mike O'Connor" <mike@xxxxxxxxxx>
> An: dssa@xxxxxxxxx
> Datum: 11.01.2012 14:52
> Betreff: Re: [dssa] hm. does anybody have an authoritative source for 
the definition of "core registry functions"?
> Gesendet von: owner-dssa@xxxxxxxxx
> 
> 
> 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"

Strongly in favour of the latter

> 
> 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-continuity-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.htm#a
> > nchor3 (see Section 3 of the 2007 Registry Failover Report)
> > 
> > 
http://www.icann.org/en/registries/continuity/gtld-registry-continuity-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.)
> 
> 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



<<< Chronological Index >>>    <<< Thread Index >>>