ietf
[Top] [All Lists]

Re: where the indirection layer belongs

2003-09-07 13:35:38
Robert Honore;

I would also prefer not to modify any of the 
libraries or implementations of those protocols, lest we break something.

It is a wrong requirement wrong in various ways.

First of all, we must change something, which means we must change
some code.

Though the changes should better be simple, whether the changes can
be inserted as a module or not is irrelevant,

To make the changes simpler, the modification MUST be confined in
libraries or kernel. So, we should try to change libraries or kernel
to avoid changes on application code.

It, of course, is necessary to change application code for UDP
cases for address selection that it is necessary to an API
to control address selection in IP headers from applications
that IP and transport layer code MUST be modified .

Secondly, preservation of code is less important to preservation
of protocol and protocol is defined on the wire.

If you put some code below transport layer to modify packet content
visible from the transport layer, which is the case with MAST, you
change the transport layer protocol.

But, again, we must change something of the protocol.

So, the requirements are:

        to modify existing code

        to modify existing protocol

and any attempt, including but not limited to MAST, to avoid them
is not constructive only to constraing the solution space to
result in less capable and less efficient solutions.

Of course, it is desirable

        to preserve existing application code

whenever possible. But, we must be aware that it is NOT always
possible.

In addition, it is desirable

        to preserve interoperability with existing protocols

which automatically means "to preserve interoperability with existing
code of the peer". In this case, it is doable. Of course, all the
freedom to use multiple addresses is lost when the peer is a
leagacy one.

                                                        Masataka Ohta