RE: multi6-functional-dec and re-homing

[<john.loughney@nokia.com>]

Kurtis,

> On 2005-01-17, at 13.52, <john.loughney@nokia.com> wrote:
>> Could I suggest a change to the current charter:
>>
>> From:
>>
>> 	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
>>
>> To:
>>
>> 	MAY 05    First draft of architectural and protocol document
>> 	MAY 05    First draft on cryptographic locators, if required
>> 	MAY 05    First draft on failure & rehoming event description
>>
>> This is, of course, not considering the discussion we have had about
>> the
>> potential need for a seperate architecture draft.
>>
>> Anyhow, State management to me, means the internal protocol state, and
>> message processing rules, etc.  For example, I think
>> draft-arkko-multi6dt-failure-detection-00.txt might cover some of what
>> I'm thinking about. I also wonder if any of the work in DNA could
>> also be referenced here.  I'm definately interested in contributing
>> on this topic.
>
> so having thought a bit on this, and started working on an updated
> version of the charter. I originally put in the state machine document
> to have the entire document set somewhat more "modular", but also
> because I thought that making an conscious effort to try and develop
> the statemachine. After reading the mails here, Johns mail on the
> "interaction" with transport made me think that having these as to
> separate documents probably is a good idea - as we might want to change
> state interaction with transport without changing protocol elements.
>
> As for the proposal above to change the name, isn't failure and
> rehoming also somewhat misleading as sate is also establishment and
> disconnect (I guess also somewhat along what Marcelo pointed to)?
>
> I am for keeping this as a separate document, but I am open for
> suggestions on names. I will try and write some more text explaining
> the context/content of the document....

I cannot think of a good term - in the initial charter, I interpreted
state to be internal protocol state; but there are a lot of other related
types of state that the seperate document should cover, in my opinion.

John