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

[Brian E Carpenter <brc@zurich.ibm.com>]

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.

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