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

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

Hi,

El 14/01/2005, a las 12:09, Brian E Carpenter escribió:

First, yes, an architecture document would be no bad thing
(and in fact I think Geoff agreed to write one at the last IETF).

<no chair hat on... this is a pre-BOF discussion>

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.


yes, this was my interpretation of the text of the draft.
i mean, i agree with Erik that the protocol spec should define how packets exchanges affect the state machine.
However, there are plenty of other events that will affect the event machine, like triggering alternative path exploration upon reception of icmp messages or interaction with apps and transport that i can see in a separate state management document. (perhaps the name of the doc is not very accurate...)

Regards, marcelo

To me this *does* tend to argue for a separate document. But I certainly
agree it can't be developed sequentially.

   Brian

john.loughney@nokia.com wrote:
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