IETF mission (RE: pausable explanation for the Document Series)

[John C Klensin]

--On Friday, 06 June, 2003 13:50 +0200 Brian E Carpenter 
<brian at hursley.ibm.com> wrote:

> In any case, since we don't actually use the complexity we
> already have (3 grades of standard), the need is clearly to
> *simplify* the document scheme, not to complicate it. My
> thinking is getting more radical the longer this discussion
> continues. Let's think seriously about
>
>  Problem: the 3 step standards track is largely fictional
>
> and possible solutions along the lines of
>
>  Solution: let's scrap it and have all "standards" RFCs as a
> single level  (with recycling in grade for
> corrections/updates).

Sigh.  I wondered how long it would take us to get there.

Several years ago, when it became clear that the efforts (and 
investment) on OSI were going nowhere, and that TCP/IP was 
taking over, many of the "traditional" standards bodies went 
into a huge excursion of "future standards planning" in which 
they tried to map out a future in which users and industry 
didn't automatically come to them every time a standards issue 
arose.  From their perspective, that (and bodies like the IETF) 
were problems that needed fixing.

Now there was a subtext in some of those concerns, which might 
have been stated as "how do we professional standardizers, 
process experts, and generalized go-ers (thanks, Marshall) who 
haven't done real engineering and design for years (if ever) 
keep our nice jobs, frequent flyer miles, and fine lunches and 
dinners?"  but, regardless of the motivation, the problem 
remained: what were groups like the IETF doing that they needed 
to imitate, co-opt, or defeat?

There were several answers:

(1) We didn't standardize fantasies about where the industry was 
likely to go, or where we wanted it to go.  No "anticipatory 
standards" here.  Documents didn't advance to full standard, or 
even draft standard, unless there was solid implementation 
experience.

(2) We didn't have a mandatory five-year (or other) review cycle 
that led to permanent WGs dedicated to each [group of] 
standards, provided a full-employment situation for WG chairs, 
and virtually guaranteed second-system effects (while the 
initial development WG often contained solid engineering 
expertise and was usually in touch with real customer and 
product requirements, and the first review cycle might contain 
some of those people in order to fix bugs that had been 
discovered, by the time of the second review (third time around) 
sponsoring companies had almost always pulled out the useful 
designers, replacing them with people whose fantasies about 
improvements usually exceeded their experience and knowledge).

(3) We were reluctant to simply declare an old standard obsolete 
and replace it.   Instead, we worried a great deal about 
compatibility and interoperability between old versions and new 
ones.   And we didn't "withdraw" the old documents from the 
marketplace, making copies of it essentially unavailable.

(4) We didn't try to support the standards process, or its 
bureaucracy, by either selling standards (and tight control over 
copyrights to make that feasible) or extracting high 
participation, "membership", or "service" fees from participants.

(5) Partially as the result of (4), we enabled and encouraged 
participation by interested and dedicated individuals and also 
from academics and researchers (not just corporations, 
government bodies, and institutional IT departments).

(6) Our key participants were still rooted in products -- 
developing code, determining requirements, doing leading-edge 
research in the relevant technologies -- rather than being 
full-time standardizers or process experts.

The "optimists" within those traditional standards believed that 
all of the above were just the result of our lack of 
organizational maturity.  They were convinced that, as age, 
scale, and a sense of responsibility toward the marketplace 
caught up with us, much of the above would disappear and we 
would turn into "them".

I thought they were wrong.   I'm beginning to wonder.  Note, for 
example:

(i) We have apparently succeeded in turning the IESG into a full 
time job.  Some of the members are essentially lent to us for a 
while from the product-rooted jobs identified in (6) or are 
still trying to do IESG along with day jobs.   But we are, at 
best, on a slippery slope.

(ii) More and more of our proposed standards are approved at "we 
generally think this is a good idea" phase, rather than on the 
basis of solid experience along at least some dimensions.  That 
is ok, because we still have Draft and Full standard levels... 
whoops, we are now talking about dropping those (note that this 
has nothing to do with whether or not those two grades should be 
combined).

(iii) We are talking about semi-permanent "maintenance WGs".  It 
may well be a good idea, and better than any of the 
alternatives, but it takes us away from the "WGs get formed 
around a specific function, do their work, and then dissolve" 
model... and we had best be careful what we wish for.

(iv) Meeting fees have reached a level we would have considered 
inconceivable a decade ago, and we have considered shifting more 
authority and responsibility to the Secretariat and other 
IETF-paid professionals as a means of reducing load on the IESG 
and/or WG Chairs and Editors, etc.

Hmm...

    john