Re: multi6-functional-dec and re-homing

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



I managed to screw up the To address on this mail...

Begin forwarded message:

> From: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>
> Date: den 18 januari 2005 09.58.52 MET
> To: <shim6@psg.com> <shim6@psg.com> <shim6@psg.com>
> Subject: Re: multi6-functional-dec and re-homing
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> 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....
>
> - - kurtis -
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.1
>
> iQA/AwUBQezP06arNKXTPFCVEQKxugCggpVDuhlCkIi5Ab2gaQDBm10FGdEAn0/S
> SlN5Z65lV7Vo/eK2+J2+lz/Q
> =R2HV
> -----END PGP SIGNATURE-----
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQezcZqarNKXTPFCVEQJRKwCg6B1J5ky/bwsq83HHSnSTha/p9LUAoMGw
HtF6bs1kpYcg1VFXeo29G2fe
=sRlp
-----END PGP SIGNATURE-----