RE: State machine / failure detection / rehoming support

[<john.loughney@nokia.com>]

Hi Joel,

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

I am as well.
 
> 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.

One could imagine writing an applicability statement for different services
or uses for shim6 - applicability for realtime services, tcp services, udp services
and so on.  Is this similar to your 'service definitions'?
 
> 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.

Agreed.

John