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