[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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




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