Melinda, Peter, Dave, and Brian,
I wanted to try to describe some fundamental models and their
implications but avoid leaping head first into either the "fix
the standards process" or "change the categories or content of
the RFC Series" rat holes. However...
--On Wednesday, May 29, 2013 09:38 -0800 Melinda Shore
<melinda(_dot_)shore(_at_)gmail(_dot_)com> wrote:
Proposed Standard on that basis is then proposed for
advancement to Internet Standard, I think the review should be
comprehensive --perhaps even more comprehensive than the usual
such review-- because the Internet Standard is unambiguously
an IETF product and recommendation not that of the other
body.
I'd actually much prefer to see these go to informational, if
they're to be published. Otherwise I agree - if something's
going to be an IETF standard it needs to go through the IETF
standards development review and revision process, which is
probably not what the authors want.
While I agree with the preference, I didn't mention it because I
assumed, for the purpose of my analysis, that the choice of
"standards track" or not was outside my logical scope. I suggest
we've done it both ways, e.g., with NFS, we published Version 3
as Informational (RFC 1813) and then produced Version 4 on the
standards track (RFC 3010). HTTP was pretty much the same: 1.0
was pretty much taken over from W3C and published as
Informational (RFC 1945); 1.1 was a Proposed Standards in RFC
2068. DKIM, IIR, went directly to Proposed Standard (RFC
4871ff) based mostly on an external spec (RFC 4870 appears to
represent a somewhat different protocol). There are probably
better examples of the latter. My guess is that cases will
differ and trying to make a hard rule would just get us into
trouble.
--On Wednesday, May 29, 2013 11:42 -0600 Peter Saint-Andre
<stpeter(_at_)stpeter(_dot_)im> wrote:
/me wonders if we need a separate series for informational
documentation
I'm not sure what you are suggesting. If it is "time to get
informational documents out of the RFC Series", the community
has considered variations on that theme endless times and been
unable to reach consensus that it is a good idea (and has
sometimes reached consensus that it isn't). In particular,
putting them in a separate series would complicate the model of
publishing externally-produced specifications as Informational
and then following up with Standards Track, IETF designed and
vetted, specs discussed above.
If it is time to rethink the categories of RFCs and/or those of
the standards track as Dave suggests... well, I've tried
floating several of those proposals and gotten absolutely no
traction. If you want to try, I promise to cheer supportively
from the sidelines.
--On Thursday, May 30, 2013 08:44 +1200 Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
Where we get into trouble seems to be when people want a rubber
stamp for something that doesn't make the cut for IETF
consensus. We have a little trouble saying "No." But I think
we have a duty to say "No" when something works but is
believed to be bad for the Internet as a whole.
Yes, and the latter is implicit in my long note. The even more
difficult problems arise when someone comes to us with a spec
that might be ok but isn't how we would do it and tries to say
"you can have this and we will turn over change control as long
as you don't really want to make any changes". When a statement
equivalent to that is justified on the basis of either being in
a hurry or not invalidating existing implementations, we find
ourselves in the middle of the contradiction between "consensus
of industry practice" and "best engineering solution" for
standardization.
best,
john