If people want to proceed quickly then we would do better to look at the WAY
we do business rather than the business that is done. I have participated in
three WGs that have delivered standards in this field within a year. I have
also watched MARID disintegrate.
If there is to be an avoidance of the experience I suggest:
* Bi weekly conference calls
* Requirements document
* Specification developed in parallel.
* Issues list
* Distribute drafts in format that shows editing changes
None of these runs counter to any IETF policy or principle. The plaintext
requirements are only binding on the publication by the RFC editor. There is
nothing to stop the working group using readable drafts. The only
requirement on communication technique is that the Internet be used, well
the Internet subsumed the telephone network years ago.
If the IETF does not want to allow the working group to conduct this process
in a responsible manner using the best modern professional tools then get
out of the way.
With respect to the requirements document issue, nobody is suggesting a
waterfall model. My usual practice is to develop both the requirements and
the specification simultaneously.
With respect neither Andy's nor John's examples are relevant here, we are
developing a specification, not an implementation. Spiral and waterfall
comparisons are irrelevant.
What we really need to do is to do some experiments to see what gets through
the network and what does not. In particular we have to see what the
behavior is between the edges. The Edge-Edge case is trivial and not a
problem, the Edge-Relay-Edge and Edge-Relay-Relay*-Edge cases are the ones
that are critical.
If we write out a requirements document my strong belief is that virtually
every requirement we might want has already been met in some context and
that there is remarkably little conflict between meeting different
requirements. Yahoo, Cisco and VeriSign have all developed independent specs
that meet this need in pretty much the same way. Microsoft, PGP and VeriSign
have also gone down the MIME route.
I don't much care for opinions on the list as the means of deciding which is
the best approach. The only thing that will convince me is empirical data.
If it turns out that we have a solution that works 95% of the time then
stick a fork in it, its done, 90% less happy, 80% we get into tradeoffs, 50%
then we have real trouble. But lets find out what the values are.
Phill