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

Re: State machine / failure detection / rehoming support

I am wondering if the split being discussed is actually different from a protocol / FSM split.

What is described seems very close to produce "service definitions".
We could write a document which described the exxternal behavior that shim6 provides, and a separate document describing the protocol that meets taht "service definition". This is the normal practice in other standards bodies.
It is sometimes useful for IETF protocols. (The Forces transport mapping layer will probably be defined this way, with luck.)

However, this often introduces a degree of complexity, and an extended argument about whether a given behavior is necessary, or must be visible, etc...

The issue probably turns on two aspects:
1) The degree of complexity of the service specification. If it is easy, then it often is helpful and sufficient to carry it in the protocol document, but in a clearly separated early portion. On the other hand, if the service description and the interactions of the aspects of the service behavior are complex, then there may be good reasons for a separate service document.
2) There is also the dimension of the degree of variation in supporting protocols we anticipate / desire / ... If the variation is very small, then there is not much point in worrying about it. If the variation is extremely large, then even a separate service document won't help. In the middle range, the separation can be helpful.

At the same time, I have real trouble separating the finite state machine of the protocol (as opposed to the states seen by the shim6 user) from the definition of the protocol.

Yours,
Joel

At 02:28 AM 1/18/2005, Brian E Carpenter wrote: 
<hat chair=off>

I still disagree. As I said before, I am very concerned that we shouldn't
preclude later changes/enhancements (imagine introducing HIP identifiers,
for example) and that means the shim6 protocol needs to be clearly
separable from the shim6 state machine. So without disagreeing at all with
John's comments on state machines, triggers, etc - I'd like RFC-statemachine
to be separate from RFC-protocol.

    Brian
</hat>