Re: Fwd: A comment about MAST

[Dave Crocker <dhc@dcrocker.net>]

Eugene, et al,

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

EMK> Not verbatim.  In order for that to work, a new protocol is needed
EMK> between a NAT gateway and machines behind it so the gateway can notify
EMK> address changes to them.

NAT boxes do address translation and MAST does address translation. In a very
theoretical sense there is, therefore, some similarity between them. However
MAST is not a "network" address translation service and it really has nothing
to do with the controversy surrounding NATs.

So I am not understanding criticism of MAST that is essentially a continuation
of the criticism about NATs.  They are separate and I think the debates should
be kept separate.

As for a "MAST API", none is needed.

MAST hides the multiple addresses from transport and above.  That is one of
its features.

I believe that any application protocol that uses direct IP addresses has a
problem with any multi-homing/mobility solution.

Also, as soon as the application needs to benefit from knowing about -- and
giving guidance about -- the availability of multiple addresses, then it needs
an be nice to enhanced API. That is true for any multi-addressing solution,
not just MAST.


EMK> To the best of my knowledge, none of the
EMK> existing IETF protocols do this, much less can MAST.

Correct.


EMK>   I think you are
EMK> worried about something that does not even exist.

Correct.


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

EMK> I'm afraid you did not communicate what was `*THE* problem' you were
EMK> trying to solve here.

Yes, it would be nice to hear a clear and coherent description of "the"
problem.


d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>