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 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." > 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? 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. I'm not convinced that it's an either-or proposition, with automagic needing to be disabled (or worked around) in order to run "special" applications. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
