Re: Start running

[Brian E Carpenter <brian@hursley.ibm.com>]

Noel, I agree with what you say about the facts, but I think
it did amount to a technical "deep dive". Unfortunately, we never
resurfaced.

  Brian

"J. Noel Chiappa" wrote:
> 
>     > From: Brian E Carpenter <brian@hursley.ibm.com>
> 
>     > the 8+8 experience was that you have to go a long way into the
>     > details to find out if a solution is really useable.
> 
> No. It was instantly clear to people who are used to thinking at an
> architectural level that the 8+8 approach (as outlined by Mo) would do what
> he wanted, but had two areas of concern:
> 
> - how to protect the binding between location and address
> - for "full-on" 8+8 (as originally posited by Mo), where/how the RG was
> added/modified
> 
> Solutions to the first problem were instantly obvious (either don't allow a
> change in the binding for the duration of a connection, or crptographically
> secure it). I will concede that solutions to the second problem weren't as
> obvious, and I'm not sure this was ever looked at thoroughly.
> 
> Later discussion served to illuminate these points a bit (although not in
> the case of the famed analysis I-D, which was severely flawed), but not in
> any significant way.
> 
> There were also other areas of what I will call "interest", which are to
> say areas where 8+8 offered the *potential* of improved functionality (over
> the baseline IPv4/v6 architecture), provided appropriate mechanisms could
> be developed.
> 
> An example would be using 8+8 as part of a mobility solution - you still
> have to deal with all the tricky bits like "what happens if you want to
> contact a mobile host and the current identity/location binding you have
> for it is not current".
> 
> It's only when you look at the mechanisms needed to handle that case
> (mechanisms which will depend on how you handle other things) that you can
> decide whether that that case is not worth solving - i.e. that the
> mechanism is too complex/expensive compared to the cost of just ignoring
> that case.
> 
> It should be self-obvious that only when you have detailed mechanisms in
> hand can you evaluate whether the mechanisms used to handle particular
> cases are cost-effective.
> 
> Perhaps this is more what you were thinking of in your comments above?
> 
>         Noel