[RPRWG] Summary of State Table Ad Hoc conclusions:

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Results of the State Table Ad Hoc:

The State Table Ad Hoc held two teleconference meetings following the New Orleans interim. By the conclusion of those meetings we were in unanimous agreement and have concluded the following:

The state tables in Draft 1.1 are a good start at describing the RPR algorithm, but fall far short of what is required. The following changes and additions are required:

1) The format used to describe conditions and actions are a combination of English and formal language such as C-code. Formal language expressions tend to be much more precise and should be used wherever possible to reduce the ambiguity associated with interpretation of the state tables. C-code is a good candidate formal language.

2) Where there are multiple input conditions to be evaluated it is critical that the reader understand whether or not any of the conditions/actions take precedence over the others. There are a number of ways of addressing this concern. One is to state explicitly that there will be a top to bottom precedence to the actions unless explicitly noted otherwise. Another is to have a table that lists all of the possible combinations of simultaneous inputs and the corresponding actions and states.

3) Input conditions are specified but the variable that carries that input condition is not explicitly referenced. There needs to be a clear and easy way to get from the input condition to the variable carrying that input condition, to the set of values that the variable may assume. One place to do this is in Clause 4. For example, in Draft 1.0, page 44 RI is defined as ringlet identifier. That definition should refer to Clause 8.2.1, where RI is formally defined. SD is defined as signal degrade. The definition should specify the variable that contains that information and the other values either by referencing a table in later clauses or by listing with the definition.

4) Specifying MIB updates within the table will greatly simplify the final review phase of the document, making sure that the all important MIBs are consistent with the text.

5) The most critical deficiency in the State tables is that there are a very large number of input conditions and states that are not addressed at all. Everyone is asked to study the state tables in 1.1 very carefully with an eye toward finding what is still unspecified. Some of the unspecified actions will be described within the text. Some will not be described anywhere, and represent potential holes in our draft. All of these omissions should have a Technical Disapprove associated with them. Filling in the state tables stands alongside reaching agreement on our algorithms as the two most critical areas to focus our attention at the November meeting.