To:
<Chris.Newman@Sun.COM>, <lisa@osafoundation.org>
Cc:
<ietf-provreg@cafax.se>, <iesg@ietf.org>
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Fri, 17 Oct 2008 08:28:31 -0400
Content-class:
urn:content-classes:message
In-Reply-To:
<F56BC6781D91EE6290D4179A@446E7922C82D299DB29D899F>
Sender:
owner-ietf-provreg@cafax.se
Thread-Index:
AckvxK8WS/n8pnKkRvGt1l+no5rJwAAg/6Lw
Thread-Topic:
Standards Track Advancement Request for EPP RFCs
Subject:
[ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs
Chris, Your mention of TLS below reminded me of a need to check the other normative references in the complete document set to see where they are on the standards track. I found three that we should talk about: In 4930: 3066 (BCP, obsoleted by 4646 and 4647) In 4931: 952 (status unknown) In 4932: 952 (status unknown), 4291 (Draft) 3066 can be addressed by updating the reference. 952 is so old that it's a de-facto standard, but since it's not on the standards track it needs to be noted. 4291: is its status a show-stopper for advancement? I'd like to have that question answered before I invest a lot of time in making any document updates to address the TLS topics you noted. Can you point me to another specification that includes a TLS usage profile that addresses the features you described? I'd like to see an example that has recently passed muster with the IESG. -Scott- > -----Original Message----- > From: Chris.Newman@Sun.COM [mailto:Chris.Newman@Sun.COM] > Sent: Thursday, October 16, 2008 3:23 PM > To: Hollenbeck, Scott; lisa@osafoundation.org > Cc: ietf-provreg@cafax.se; iesg@ietf.org > Subject: Re: Standards Track Advancement Request for EPP RFCs > > Lisa and I discussed this and decided I should take this on. > > I do have a technical issue I'd like resolved before moving > forward. RFC > 4934 is quite vague about the TLS bindings -- there's no > mandatory-to-implement mechanism, it doesn't discuss whether > or not wildcards are supported, it doesn't say if > subjectAltName takes precedence over legacy use of domain > names in CN, it doesn't say whether certificates (client > and/or server) are used or PSK is used, and doesn't discuss > interaction with the login command, and it's even vague about > whether the TLS negotiation on port 700 starts immediately > after connection. Given the excellent implementation report, > I suspect this is simply a matter of revising RFC 4934 to > more precisely document what was implemented so that an > independent implementer can replicate that. A revision would > also provide the opportunity to update the reference from > 3280 to 5280 so that IDNs in certificates are adequately > covered (probably a useful improvement). > > I haven't reviewed 4930-4933 in detail yet. Given the high > quality interop report, I suspect they would be fine without > an update. However, if you wish to republish them as well, I > can review them with an eye to improving clarity for interoperability. > > - Chris > > --On October 6, 2008 8:42:56 -0400 "Hollenbeck, Scott" > <shollenbeck@verisign.com> wrote: > > > The EPP RFC documents (RFCs 4930, 4931, 4932, 4933, and 4934) were > > published as Draft Standards in May 2007. I am asking the IESG to > > review these documents for advancement to "Standard" status as > > described in sections 6.1 and 6.2 of RFC 2026. There are > no entries > > in the RFC Editor errata database for any of these RFCs. > > > > Thank you, > > Scott Hollenbeck > > > > > > >