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

[bmanning@xxxxxxxxxxxxxxxxxxxx]

 guess you have to define "take down" along w/ "the DNS"

 sure, its possible to have a viable DNS process running.  but with what data?
 somehow, the DNS has got to have data to serve.   How do you get data into the 
DNS?
 VI? sql?  and  how do you update the sqldb?  epp?  of course!

 IDN and DNSSEC are encodings of DNS resource records. 

 Whois is right out.
 
 IDN and DNSSEC might be considered, after all are A and PTR RRs required?  How 
about AAAA?
 or SRV?  NAPTR? MX? ...  KS?  

 EPP is a means to load a database.  The database generates reports or answers 
queries that
 feed the DNS process.   Other implementation choices include  VI editing text 
files which feed
 the DNS process.   So if you include EPP, you need to include VI and Emacs.

 So, it seems that Whois, EPP, IDN and DNSSEC are -contractual- implementation 
instructions and
 are not technically required as a "core/critical service"

 YMMV

/bill


On Wed, Jan 11, 2012 at 07:50:32AM -0600, Mike O'Connor wrote:
> 
> 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-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.)
>