Standards

[Keith Moore]

> 1)  A PS is supposed to have no "known" errors.  However there is nothing
> that says that a PS is required to try to solve any particular scope of
> requirement.
> 
> That is, a PS is allowed to tackle a very narrow problem, if the PS will
> in fact do something useful.  Narrow scope makes it easier to do things
> in a more timely fashion and with a better understanding of what is
> being done.

Yes, but narrow scope also causes the elephant in the dark problem.
Failure to consider the wider effects of a particular technology early
in the design of a protocol is one of the reasons that protocols are
held up in late stages.  

A related problem is that sometimes WG get very ambitious about the
applicability of their protocols, wanting them to solve a far wider problem
set than is reasonable.

> Instead, we currently see WGs try to carve off and solve problems with
> very large scope.

The Internet is a lot bigger than it used to be. Its uses are far more
diverse.  The easy problems have mostly been solved.  The problems that remain
are inherently more difficult than in previous years. Often this is because
they have "large scope" - i.e. they touch many other areas of concern.  If we
pretend that those areas of concern do not exist or are not important, the
effect will be to produce more useless standards and more operational
problems.  Our stats might look better, but our problems would be worse.
 
> c) I believe we should NOT change the formal requirements for PS; they
> really strike quite a good balance.

I agree with this, though renaming it might be useful.
The question is, what should come before and/or after what is now called PS?

I believe that the initial efforts of a WG should often consist of
'problem definition' and/or 'scoping' (NOT requirements) efforts -
trying to understand the problem space, the interests that this protocol will
affect, the needs of those parties, and so on. This phase should produce
a brief problem statement (say < 20 pages) in a relatively short time (say 3 
months), and should be subject to IETF-wide review.  Multiple iterations might
be needed, but it's better to iterate on the problem definition than to spend
time trying to solve a poorly-defined problem.


As for post-PS stages, I would like to see periodic review of standards-track
documents to
a) correct observed problems or ambiguities in the spec
b) assess interoperability
c) assess user/market acceptance
d) clarify applicability
but WITHOUT the expectation that the original specification would be revised. 
I get the impression that we spend too much time on editorial cleanup of old
documents, with the revisions often introducing as many ambiguities as they
remove.

> d) However we should stop trying to stuff everything, INCLUDING the
> kitchen sink, in a PS effort, especially for an entirely new service;
> and we should stop nit-picking PS details.

In my experience 'nit-picking' of PS details, at least the nit-picking that
consumes lots of time, is quite often a result of failure of the protocol
designers to consider (and get wide buyin from) the various interests affected
by the protocol that are outside the WG.  IESG members can't simply reject a
protocol, they're expected to state why they don't like a document and what it
would take to fix it.  So they end up trying to find ways to fix a severely
flawed design or document that don't involve drastic changes to the text. 
Often it looks like nit picking to the folks in the WG who haven't tried to
understand the wider implications of the problem they're working on.  Of
course nit-picking a document that the WG thinks is complete is a poor way to
address fundamental design problems.  Far better would be to identify these
problems and to get wide support for the general outline of a solution early
on.

Keith

p.s. sorry for delving into solution-space; I'm not trying to steer the
discussion toward possible solutions.  the general point is that if you want
to take some of the burden off of PS, then you need to get formal buyin for
some aspects of the decision earlier, and also lessen the burden of later
stages of advancement/approval/endorsement.