[ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----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-