RE: [dssa] hm. does anybody have an authoritative source for the definition of "core registry functions"?
All, owner-dssa@xxxxxxxxx schrieb am 15.01.2012 23:23:15: > Von: Greg Aaron <gaaron@xxxxxxxxxxxx> > An: "Mike O'Connor" <mike@xxxxxxxxxx>, dssa@xxxxxxxxx > Datum: 15.01.2012 23:41 > Betreff: RE: [dssa] hm. does anybody have an authoritative source for the definition of "core registry functions"? > Gesendet von: owner-dssa@xxxxxxxxx > > > 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". I like this definition a lot better. Below a slightly modified one I'd prefer: "the receipt of data from registrars/registrants 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" This would leave it open whether or not we are dealing with a 3 tiered (registrar/registry/registrant)model or not. As some Registries do not have a formal agreement, I omitted the related part. regards Joerg > > 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.) Attachment:
smime.p7s
|