To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc:
<Chris.Newman@Sun.COM>, <lisa@osafoundation.org>, <ietf-provreg@cafax.se>, <iesg@ietf.org>, jaap@nlnetlabs.nl
From:
Edward Lewis <Ed.Lewis@Neustar.biz>
Date:
Thu, 18 Dec 2008 10:09:09 -0500
In-Reply-To:
<046F43A8D79C794FA4733814869CDF070282A322@dul1wnexmb01.vcorp.ad.vrsn.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
[ietf-provreg] RE: Standards Track Advancement Request for EPPRFCs
Scott, I admire your patience over advancing this. NeuStar has been using EPP for a long time, in a lot of ways, and reliably for our domain name registry business. We have even already implemented the DNSSEC extensions and whatever extensions have been needed for our business model. When I talk to other registry operators, EPP is nearly always mentioned. Operators have been and still are converting to it. I don't think the RIRs have but just about all TLD operators I have come across use it. Registry operators tend not to document this nor issue reports measuring this. Other tasks take precedence. Regarding the options - I've never run into any issue with the original spec, I doubt that we have updated anything for quite a while. (We did add DNSSEC extensions and some others, but nothing touching the base.) So I don't have a real opinion on the needed changes. (As in I don't think/know of anything [is] needed.) At 8:29 -0500 12/18/08, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] >> Sent: Monday, December 15, 2008 11:58 PM >> To: Hollenbeck, Scott; lisa@osafoundation.org >> Cc: ietf-provreg@cafax.se; iesg@ietf.org >> Subject: RE: Standards Track Advancement Request for EPP RFCs >> >> Apologies for taking far too long to review this in detail. >> >> I've had several discussions about where to set the bar for >> advancement to full standard status. RFC 2026 does have this >> statement: >> >> A specification for which significant implementation and >> successful operational >> experience has been obtained may be elevated to the >> Internet Standard level. An >> Internet Standard (which may simply be referred to as a >> Standard) is characterized >> by a high degree of technical maturity and by a generally >> held belief that the >> specified protocol or service provides significant benefit >> to the Internet community. >> >> I believe the implementation report fully covers the first >> sentence. I would want an answer for the second sentence >> before going forward with this >> -- certainly domain registration is a significant benefit to >> the Internet community, so to answer this question, I'd like >> a rough idea about how often this protocol is used in >> production between vendors for domain registration. Do you >> have any information on that? > >Depends on what you mean by "how often". It's used for several million >transactions per day between VeriSign and registrars managing .com and >.net domains. I don't have direct access to production stats for other >registry operators, so I'd like to ask others to speak up here as >appropriate. > >If you're asking about overall adoption, I know that it's used by all of >the gTLD operators (it's an ICANN requirement) and many ccTLD operators. >Patrick Mevzek recently reported on recent deployments here: > >http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cair >o-ccnso-techday-200811.html > >Sorry if the URL gets broken across two lines. > >> Beyond that, I think the bar should be set very high before >> permitting _changes_ during the advancement from draft to >> full standard. After talking with other parties, I suspect >> that while my concerns about TLS would improve the quality of >> the specification, they are not something I feel the IESG >> should force an author/WG change during this advancement >> (it's something I would strongly favor for republication at >> proposed or draft, however). >> >> I don't feel any of the normative references are >> inappropriate for an RFC >> 3967 downward reference. >> >> 1. Move RFC 4930-4934 to full standard without change. I am >> willing to attempt this, although it's less likely to pass >> IETF last call than the other options due to the obsolescence >> of some of the normative references. >> >> 2. Republish with only references updated. This will require >> somewhat less use of the RFC 3967 procedures and make improve >> the odds of a successful last call. >> >> 3. Republish with references updated and operational >> clarifications; primarily documenting the TLS practices that >> have been used in practice to interoperate. I recognize >> there is some risk that the new TLS practices text will not >> be correct, which is why I've decided I'm willing to let this >> issue pass for a draft->full advancement. IMHO, the problem >> should have been noticed and fixed when advancing to draft so >> any errata could be applied when advancing to full. We >> missed the window where it was most appropriate to fix that >> sort of problem, so we shouldn't hold advancement hostage >> over the issue, IMHO. I can't promise my the rest of the >> IESG will agree, but that's my opinion. >> >> So the steps to advance are: >> >> A. Provide data for the "significant benefit to the Internet" >> litmus test. >> I'll need to >> defend this before the IESG. >> B. Choose option 1-3, publish revised I-Ds as appropriate C. >> It would be very helpful to provide candidate RFC 3967 text >> for the last call notice. >> >> and I'll take it forward from there. > >I'm open to either option 2 or 3. What do others think? > >-Scott- -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Never confuse activity with progress. Activity pays more.