Re: API, was: Question re HIP dependency & some architectural considerations

On 29-jul-04, at 15:10, Pekka Nikander wrote:

>> Please define "use multihoming".

> To me (and I may well be wrong), it looks natural for wedge/layer 3.5
> solutions to maintain a host-to-host (or end-point-to-end-point)
> state that is relatively independent on transport state.  That is,
> such state is probably created on demand on first TCP connection
> (or SCTP or UDP or ...) and it stays around some time after all
> connections are known to be closed, just in case that there would be
> more communication.

I think Marcelo has made it clear that something like this can only 
work securely when there is a strong binding between the identifier and 
the locators, if not the risk of long-time redirection is too big.

But even in a scenario like this and not a per-session one, I'm not 
very comfortable with mandating extra initial delays if they are 
avoidable. (I believe they are in a routable identifier setup (where 
strong bindings aren't easy to come by) but not with unroutable 
identifiers (which need the strong binding anyway).)

>> The trouble with doing something right the first time is that nobody
>> appreciates how difficult it was. - Walt West

> Some people say that there there are two schools in CS in the US.
> One is the MIT way, "do the right thing".  The other one is the
> UCB way, "just do it".  I don't know whether the saying is true or
> not.

> In other words, I also see some value on incremental and partial
> solutions.  Trying to do it right the first time, in a committee,
> may well be pretty impossible.

The thing is, if you try to do something perfect you're likely to fail, 
but if you try to do something imperfect you're likely to succeed. The 
questions is whether the failed result from the former is better than 
the successful result from the latter.

There are very real costs involved with the additional steps in going 
back to add stuff later. There is no excuse for creating a standard 
with known and fixable (circumstances permitting) flaws, as this 
creates new legacy problems when the problems are fixed in a later 
version.