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: [email protected] [mailto:[email protected]] 
> Sent: Thursday, October 16, 2008 3:23 PM
> To: Hollenbeck, Scott; [email protected]
> Cc: [email protected]; [email protected]
> 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" 
> <[email protected]> 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
> >
> 
> 
> 
> 
>