On 2007-01-30 22:50, Mark Nottingham wrote:
The language Scott references ("using the latest version supported by
both parties") seems reasonable, but I think what's being asked for is
for the latest version to automatically become MTI.
I can imagine that creating considerable confusion for people using
RFCs in procurement requirements and the like. Obviously it's highly
desirable from a security PoV, but if we make RFCs refer to variable
quantities, we create great complications for the consumers of
our work.
on the other hand, we don't really want to re-issue entire RFCs just to
allow the incorporation of a new version of TLS, do we?
nor do I think it's reasonable to retroactively make a new version of
TLS MTI for an existing RFC number.
it might be that the easiest way out is to issue some number of
"profile" RFCs so that, for instance, RFC XXXX says "the version of FOO
that conforms to RFC XXXX consists of an implementation that conforms to
the requirements of RFC YYYY except that TLS 1.2 as described in RFC
ZZZZ MUST be used rather than another version of TLS."
the downside is that we'd be tempted to use these "profile" RFCs as an
excuse to list errata, and fixes for those errata, for each of those
protocols. this would delay publication and adoption, and perhaps invite
long drawn-out processes for second-guessing the original specification
like the one we saw in DRUMS. (not that I don't think DRUMS was a good
thing to do, but there was a tremendous amount of second-guessing rather
than just clarification, and I'm probably as guilty as anyone. I guess
it's a slippery slope between the two)
more broadly, I actually think that IF we can figure out how to avoid
that kind of second-guessing, we should for each of our be periodically
issuing a document that describes the applicability, current state of
maturity and deployment, and errata and fixes for that
specification...and that such documents should to some extent replace
our current use of standardization status as a means of recommending or
not recommending a particular protocol. that might help us make a
transition away from three stages (proposed, draft, full) to one or two.
Keith
