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

[Erik Nordmark <erik.nordmark@sun.com>]

> Since the solution requires state to be maintained at both ends of a 
> communication, the protocol specification and the state machine will be designed
> somewhat independently. Some state transitions may result from external
> events such as failure detection rather than from protocol events. More work
> items and milestones might need to be added at a later date to
> complete all implementation details needed.

Perhaps I don't understand how state management is separable from the 
behavior description of the protocol, but isn't the basic state 
management (when/how state is created, maintained, and destroyed) 
something which needs to be in the behavioral description of the protocol?
Thus I don't understand how state management can be a piece which can be 
done later.


> The WG will not consider items outside the above scope, such as
> interaction with mobility, transport level solutions, or alternative 
> identifier formats.
> [What other topics are explicitly out of scope?]

Perhaps we should add that taking transport level hints ("things are 
ok") into account is explicitly in scope.

> Milestones
>
>
> MAY 05    First draft of architectural and protocol document
> MAY 05    First draft on cryptographic locators, if required
> MAY 05    First draft on state managment

This might be nit-picking on the set of documents, but I think it makes 
sense to have a separate architectural document shows the high-level 
aspects of the shim and the functional pieces, and this is something 
that the WG can piece together from the input documents.

But the protocol document (packet formats, behavior including state 
management) is something that needs to be created from the functional 
decomposition and the outline in the failure detection draft.

So I think it makes sense to list those as separate deliverables
(and not have a separate deliverable on state management.)

> SEP 05    WG last-call on architectural/protocol document

Should be ok for the arch document, but the protocol document might take 
longer time.

   Erik