RE: multi6-functional-dec and re-homing

[<john.loughney@nokia.com>]

Brian,

A short comment:

> >>This would support a larger set of possible re-homing scenarios, and I
> >>think it is compatible with the wordings of re-homing definition in
> >>draft-ietf-multi6-architecture-03.txt.
> >>
> >>I had a short off-list mail exchange with Marcelo and Jari and they
> >>agreed, but recommended to solicit the list opinion as well.
> > 
> > 
> > I have no objections to the text leaving this possibility open,
> 
> ditto
> 
> > but I 
> > have some more concerns about actually implementing this.
> 
> In a sense, it's to leave this door open that I've been arguing
> over on shim6 that we should separate the state machine (and by
> implication, its APIs) from the shim6 protocol.

This is really a shim6 discussion, but if that is what you mean by 
the charter text, then I think the charter needs to be clarified.
It sounds like you are talking about the re-homing events or triggers
where, which I think should be documented seperate.  However, in
a classical state machine, you don't need to detail the events or
triggers which cause the state change, but just the transitions
between the states.

I would support a document (in shim6) that covers the different
re-homing events, etc.

John