Re: Fwd: A comment about MAST

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Eugene;

> > 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.
> 
> Do we have to modify FTP further than RFC 2428 in order to accomodate
> MAST if it provided the API to get the up-to-date peer address for the
> control connection?  If so, why?

What is your point?

RFC 2428 is "FTP Extensions for IPv6 and NATs" and, as I said, "the
peer also need modification".

It is nothing more than an illusion that NAT/MAST were transparent.

> I thought it would be rash to draft, implement and adopt something as a
> standard in such a short timeframe that existing needs need not be met
> at all in the meantime.

Good argument against MAST, which does not worse implementation and
adoptation effort.

We should deploy only a long term solution with the interoperability to
leagacy protocols in mind.

> > Worst, your hidden assumption is that almost all the hosts use MAST,
> > which is not a sound assumption for an intermediate, if any, solution.
> 
> MAST does not worsen the case where one host knows MAST and the other
> does not, because it is designed in such a way that it does not impede
> the transport later without first verifying that the peer also knows how
> to do it.  So it need not be worried about if the peer doesn't speak
> MAST, because in that case MAST will not kick in but the communication
> will proceed as if neither party knew MAST.

Exactly, and there is no reason to have MAST.

> > > 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.
> 
> Again, you seem to be assuming that we can come up with the long-term
> solution in a really short timeframe.  Unless you can show me some
> proposal is already up for that task, including deployment plans and
> scenarios, I still think such an assumption is rash.

As was presented at Vienna, the long term solution based on LIN6
is running and is interoperating with leagacy stack.

							Masataka Ohta