RE: Standards Track Advancement Request for EPP RFCs

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: [email protected] [mailto:[email protected]]
>>  Sent: Monday, December 15, 2008 11:58 PM
>>  To: Hollenbeck, Scott; [email protected]
>>  Cc: [email protected]; [email protected]
>>  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.