[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Mailing list and draft charter for new multihoming BOF/WG
> 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
> > 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.