Subject: RE: multi6-functional-dec and re-homing

From: <[email-masked]>
Date: Mon, 17 Jan 2005 13:17:28 +0200

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

---

From: <[email-masked]>
Date: Mon, 17 Jan 2005 13:26:00 +0200

Kurtis,

> I have no objections to the text leaving this possibility open, but I 

I think we discussed this at the interim last June, to some extent.  I think
that defining what would be a 'more prefered path' would be.  However, that
could be based on local policy and out of scope for standardizing.  So, in
summary, I would support the text.

John