Hard problems [Re: Standards]

Brian E Carpenter brian at hursley.ibm.com
Wed Feb 26 15:37:08 CET 2003


Keith Moore wrote:
> > 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.

So, we have a problem about how to tackle hard problems (a.k.a. 
architectures in some circles). I think you'll find that is already 
covered in the draft, so I'm not sure we're advancing the charter here.

I will comment, however, that the Global Grid Forum, although
a beginner in this game, has already come up with a solution
to this problem: when a topic XYZ is too hard for one WG, but too
limited to be an Area, make a master WG that owns the XYZ architecture,
and several specific WGs and RGs that own subtopics of XYZ, once
the architecture is roughed out. It's too early in the life of the
GGF to see if this really works, but it does offer a constructive
approach to the mega-WG issue.

> p.s. sorry for delving into solution-space


More information about the Problem-statement mailing list