Models of building platform standards

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]