Dave Crocker wrote: > > > Jim Fenton wrote: >> Dave Crocker wrote: >>> The first version of SSP that is standardized needs to have a much >>> shorter and simpler decision tree, if interoperable deployment is to >>> be achieved anytime soon after publication. >> >> This reminds me of the famous line in the movie "Amadeus": "...there are >> simply too many notes, that's all. Just cut a few and it will be >> perfect." > > Jim, > > Were my suggestion equally whimsical, the Amadeus reference would be > apt and possibly even clever > > Unfortunately, it was based on extended observation of what seems to > deploy and get used, versus what does not.
Forgive my attempt to insert a bit of levity into the discussion. We mustn't have any of that. > > >> The length of the decision algorithm (not really a tree) is determined >> by the functionality that WG consensus decides upon. If we decide to > > You are expressing a view that means that there are no other forces > than wg consensus that affect the success of a protocol, and I suspect > we all know that is not true. > > Each of the many OSI protocols represented working group consensus. > (For those who have not had the delightful experience of attending > such meetings, they work on unanimity, not rough consensus. In other > words, they set the filter bar higher than the IETF...) > > IPv6 represented working group consensus, yet it produced something > that has yet to gain critical mass in 15 years. > > And so on. > > Complexity and strong *market* consensus (ie, market pull) about what > is needed are fundamental forces affecting protocol success. As for > complexity, I specifically cited challenges in reaching high levels of > interoperability. > > >> eliminate some functionality, such as the "testing" flag, the decision >> algorithm can be made simpler. However, simplification of the decision >> algorithm is not a suitable issue itself; it's something that may happen >> as a result of other decisions made by the Working Group. > > Complexity of design and its impact on interoperability is not a > "suitable issue"? Wherever did you get that view from, Jim? Complexity is clearly relevant, and should be a consideration in everything we do. My point about this particular issue is that it's seeking to do something about the dependent variable (the number of steps in the algorithm) while we should be dealing with this at the root cause (e.g., removal of the testing flag). -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
