Subject: Models of building platform standards

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 8 Aug 2013 12:13:01 -0400

The situation with CBOR illustrates a difference of design philosophy that
I think is of much wider relevance. Consider the normal process of
engineering design:

1) Use use cases to develop requirements
2) Perform triage on requirements to focus on most important ones and
3) Implement
4) Test, if necessary return to 1, 2, 3

What makes platform standards different is that the criteria for performing
triage are very different. In normal engineering the engineer talks to the
product manager and puts a dollar cost on each of the various features the
product manager asks for. Which is often guesswork but the engineer is the
person who will suffer if the guess is wrong.

[If the engineer works for Dilbert's boss, it is the pointy haired one who
makes the commitments]

In platform engineering the ultimate use of the platform is unknown and so
triage is not driven by a cost/benefit analysis in the same way. So what
tends to happen is that Working Groups attempt to limit the requirements to
the absolute minimum in order to make the specification as simple as
possible.

The unfortunate fact is that this frequently produces the exact opposite
outcome. PKIX is a very complex standard because it has grown to meet
requirements organically. As a result it has three certificate issue
protocols, two mechanisms for revocation and still lacks a standardized
discovery protocol. When I was asked to design a successor for PKIX in XML
back in 2000, I implemented every feature of PKIX in a 20 page spec. The
spec later formed the basis for the assertion layer in SAML and XKMS where
they did get larger, but nowhere near as large as PKIX.

So I think the approach is broken. Instead of trying to do triage by
limiting use cases and requirements before considering design alternatives
we should instead rank them. So no use case that meets a minimal criteria
of plausibility is rejected but it is understood that the final design need
not cover all the use cases.

The reason for taking this approach is that having to deal with a large
number of requirements forces people to consider a higher level of
abstraction rather than the 'one off' approach that tries to avoid
complexity in the short term by adopting design approaches that are sure to
result in horrors later.

-- 
Website: http://hallambaker.com/