Re: Fwd: A comment about MAST

["Eugene M. Kim" <gene@nttmcl.com>]

Hello,

Thank you for the pointer.

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?

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.  I am
also assuming that MAST will be deprecated in a strong manner with,
for example, a MUST clause in a formal deprecation document.

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

1. They wait until the long-term solution is established, then opt for
the new solution, once and for good.
2. They first opt for MAST, then later switch to the new solution.

Opting for MAST and not switching to the new solution is not an option
here because MAST will be deprecated (for example, it will not be part
of newer operating systems).

One may argue that `application authors will try to save time by
just waiting for the new solution, so the MAST API does not have any
merit'.  However, I do think that there will be a number of application
authors who feel they need MAST despite the additional work involved
because they decide that the amount of work is outweighed by other
reasons that call for MAST, e.g. customer feedback/market pressure.

Thanks,
Eugene

On Fri, Sep 12, 2003 at 03:06:15PM +0859, Masataka Ohta wrote:
> Eugene;
> 
> > Anyhow, here's the link from the web archive:
> > http://ops.ietf.org/lists/multi6/multi6.2003/msg01598.html (displays in
> > ISO 8859-1).
> 
> OK. My comment on the API extension is right on the thread at:
> 
> 	http://ops.ietf.org/lists/multi6/multi6.2003/msg01586.html
> 
> I'm afraind you still don't recognize the technical nature of the API.
> 
> 							Masataka Ohta