RE: multi6-functional-dec and re-homing

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.
> >=20
> >=20
> > I have no objections to the text leaving this possibility open,
>=20
> ditto
>=20
> > but I=20
> > have some more concerns about actually implementing this.
>=20
> 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=20
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