|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Hi - after some conversation with Mike, here is my view of TP3 (& 2) testing and some suggestions. Much of this has already been expressed by others.
I have 3 goals that are not mutually exclusive:
1. The tests should reasonably assure interoperability;
2. The tests used should be common and consistent among all users;
3. The tests should be as simple as possible.
Are there more?
Questions to ask:
Can we agree with a set of goals?
Can we get some agreement on what is meant by "reasonably". There is no such thing as the perfect test, but how rigorous do we want to be?
An important point - there is a difference between rigor and complexity. I generally tend towards rigor, but also prefer simplicity. Due to schedule pressures, 802.3ae did not find the right combination, and in fact, it could be argued that we did not do completely well in either aspect.
Willingness to compromise?I believe the philosophical positions in our case are approaching the goals from different starting points. As long as the group that wants to start with simple tests is willing to add components as justified by rigor, and as long as the group that want so start with complex tests is willing to remove test components as justified by simplicity, we should be able to get through this. So to me, I want to stand in the middle as long as I sense a good attitude of willingness from each direction.
For me to progress, I need more information. Perhaps we can approach this apparent impasse by examining each test component that is at issue:
1. Magnitude or significance (in dB, I suppose) and how variable the magnitude is with product implementation.
2. Test implementation (setup, method - with a view on complexity, cost, time to test, etc.); Lew has suggested this already.
3. For simplification, can rigor still be assured if the test is replaced by a fixed OMA penalty term? Would the penalty be fair to all product implementations?
If we do this for the test components that are at issue (dynamic penalty, RIN - are there others?), hopefully we'll be able to gather enough information for some of us to make informed decisions. Should a smaller group be formed for each test component being discussed?
Finally, even if we do wind up with a complex test, I would like to see the document informatively (Annex?) recommend/document ways to simplify tests with extracted components (assuming it can be justified). This would encourage the goal of common tests.
phone: (425) 775-7013
cell: (206) 790-3240