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

[<john.loughney@nokia.com>]

Hi Erik,

> 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.

I agree. I think the state management document should be included in the
Architecture and Protocol document.  If there needs to be a document
split, I'd suggest having the architecture document seperate, which
would look more like a framework type of document - so informational
in nature. Then there could be a Protocol document.
 
> > 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.)

Agree, see above suggestion.

> > SEP 05    WG last-call on architectural/protocol document
> 
> Should be ok for the arch document, but the protocol document  might take 
> longer time.

I agree. Noting the pace at which the IETF moves, I think 2006 is more reasonable,
unless we have a game-plan on how to move it that quickly.

John