James Carlson wrote:
Darren Reed wrote:
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.)
The subtle but important difference is that you're talking about
creating and destroying higher-level software abstractions (tunnels),
while the original poster and I were discussing plumbing of low-level
physical (Ethernet) interfaces.
I chose tunnels because they were an easy example.
But the same problem applies to any network interface.
NWAM is designed around the principal of activating a network interface
and configuring because of what it is attached to. For a lot of
applications,
that is fine. It is a good model for a laptop that has a wireless/LAN
interface
and can be extended to file/web servers.
But the design does not include how to manage network interfaces that
are desired to be up/down/plumbed/unplumbed based on some other
characteristic.
I think these have some different behaviors and, despite what meem said,
I'm not seeing a lot of semantic goodness in being able to insert a new
adapter (or create a new VLAN), but not being able to talk about IP on
top of that interface until I specifically say, yeah, I'd like fries^WIP
with that. It's at best confusing, because it's different from most
other operating systems, and being able to say "no IP on X" is not
terribly different (at least to me) from saying "IP is down and
unconfigured on X."
So what I hear you saying is that the API needs to be fuller,
and as an example, rather than having different actions to plumb
and then add a network interface, it should be a single function.
Whilst NWAM provides us with "network automagic", sometimes what
people (or applications) want is "programatic networking" instead or in
addition to the "automagic".
I agree that being able to create and destroy tunnels used for VPNs
would be a good thing. It's less obvious to me how that should interact
with NWAM, though. Do I _really_ need to have that application doing
all of the interface configuration work?
Why not?
If it isn't obvious how it should work with NWAM then perhaps the
answer is that it shouldn't.
For an application that's
well-integrated with OpenSolaris, I think the answer is "no" -- NWAM
should always handle that job, even if there are goofy proprietary means
for determining properties.
What do you mean by "well integrated with OpenSolaris"?
Do you mean compiles and runs?
Or is bundled and part of an OpenSolaris based distribution?
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
