RE: Mailing list and draft charter for new multihoming BOF/WG

[<john.loughney@nokia.com>]

Brian,

> Now about separating state management. Firstly I wrote the
> text to retrospectively justify Kurtis's suggestion to have
> a separate document, and I don't know if I correctly read his
> mind.
> 
> Secondly, when I began to think about it, I really did see an
> argument for *consciously* designing the state machine separately
> (and logically, it should be designed first, not second).
> 
> Who's to say that we'll get the protocol right first time? It acts
> in support of the state machine, not the other way round, so the
> state machine is actually fundamental. Going to a v2 of the protocol
> probably shouldn't change the state machine, at the macro level.
> 
> Also, the state machine will not only respond to shim6 protocol events.
> It will also have to respond to unreachability signals, transport
> disconnect signals, etc.
> 
> To me this *does* tend to argue for a separate document. But I certainly
> agree it can't be developed sequentially.

It might make sense to maintain it as a seperate document, but a protocol
document usually contains things like state diagrams, state transitions, etc.  
But going into more details, there is always an argument about having a clean
protocol definition, then having a document (not unlike an applicability
statement) that goes into how the protocol is used and in what circumstances.

However, I favor having a rather spartan charter at first, to ensure that
the bof is focused and clear, rather than overloading potential charter
items that we aren't completely sure of yet.

Just my 2 cents.
John