Re: multi6-functional-dec and re-homing

[marcelo bagnulo braun <[e-mail]>]

Hi Kurtis,

El 18/01/2005, a las 10:52, Kurt Erik Lindqvist escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> I managed to screw up the To address on this mail...
>
> Begin forwarded message:
>
>> From: Kurt Erik Lindqvist <[e-mail]>
>> Date: den 18 januari 2005 09.58.52 MET
>> To: <[e-mail]> <[e-mail]> <[e-mail]>
>> Subject: Re: multi6-functional-dec and re-homing
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On 2005-01-17, at 13.52, <[e-mail]> 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)?
>>

well, i am not sure about this...
My point was about establishing new communication after an outage with 
external hosts that don't implement the shim.
This is important becuase at least in the early days, most of nodes 
won't implement shim.
Explicitly taking this point into consideration would allow to provide 
some degree of fault tolerance (i.e. the capability of establishing new 
communications after an outage) even in communications with nodes that 
don't implement the shim.


Regards, marcelo



>> 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-----
>
>