(cross-posting removed...)
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.
The charter does need to be clarified... that's one reason we've asked for a BOF. You're correct of course, the state machine doesn't have to define the triggers, but it certainly defines the points at which they will be applied.
Brian