James Carlson wrote:
...
You're welcome to the opinion, but I don't think it has anything to do
with interface stability, or determining what things you can rely on.

There are deeper issues here.  If the OpenSolaris community does in fact
do away with the need for applications that know about plumbing by
making it all automatic (as the NWAM team has prototyped, and as it
seems we're driving towards), then what benefit do we get by having
function call wrappers over a non-existent feature?

Why make easy what we wish nobody needed to do, and what we expect to
make obsolete?

Well, to express this idea in terms of NWAM, I suspect what would be
needed is to have sub-profiles that are specific to an application that exist
within a "location" based profile. But even then, that might be too generic.

For example, maybe I want to develop an on-demand tunnel protocol and
implementation. Lets assume that it's a GLDv3 interface and I want to use
my own tunnel protocol, not one of those supported by iptun (for example
openvpn.)

Now I want my application to do authentication of the remote end before
it creates the tunnel interface. The application does some sort of out of band
authentication (maybe web based) and then wants to create a tunnel based
on the success of that authentication.

My "location" hasn't changed, it could be "any" network that I'm attached
to and thus there is no reason to activate a different NWAM profile. That
might even be exactly what I don't want to do. Tieing the interface together
to the NWAM profile(s) would be an incorrect association between the
state of the application and NWAM. Thus the tunnel interface should not
be visible "all the time" as a "just in case" thing but only as required.

In this particular high level example, the state of the tunnel link is tied to
internal application state, thus it is not necessarily desirable to link the
tunnel state to the application state.

Whilst NWAM provides us with "network automagic", sometimes what
people (or applications) want is "programatic networking" instead or in
addition to the "automagic".

Darren

_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to