[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: A comment about MAST



Eugene;

> If I understood you correctly, your concern seems to be that, with the
> proposed MAST API, some applications are required to be modified just to
> suit MAST as they had to with NAT.  Is this correct?

Wrong. There is no MAST API. It is NAT API. Applications for the API
is, behind NAT, notified address of a NAT box and tell it to its peer.

Of course, application on the peer also need modification, which is
practically impossible.

Try to design the API of a host and its peer, for example, for FTP.

> Assuming the answer is yes, I still don't think it's a definitively
> prohibiting reason against the API.  I say this under the assumption
> that MAST will be just a transition protocol, or a stopgap, with which,
> again, simple applications can work without any modifications.

You miss the point that MAST does not solve *THE* problem
and is useless even as an intermediate solution.

Worse, you miss the other point that no intermediate solution
is necessary.

Worst, your hidden assumption is that almost all the hosts use MAST,
which is not a sound assumption for an intermediate, if any, solution.

> With these two assumptions, authors of complicated application (i.e.
> those that must be modified to take advantage of MAST) have two choices:

Completely wrong.

Those applications that must be modified to take advantage of
multihoming with multiple addresses have a single choice to
be modified so with no further modification.

							Masataka Ohta