Darren Reed wrote: > James Carlson wrote: >> 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.
Not necessarily. *If* you assume that plumbing (an action that's alien on any Linux or BSD system) of Ethernet interfaces is a normal action that should be under the user's direct control, then I agree that it applies in both cases. But if you don't make that assumption, and you expect all physical interfaces to be plumbed automatically, then the question is quite different. > 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. I believe it can be extended much further than that. > 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 don't believe that's true. Check with the NWAM team; what they're aiming for is a lot richer, and *does* include those "other characteristic" behaviors. >> 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. No ... I'm saying that it needs to work with rather than in opposition to NWAM. >>> 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? Because it's needless duplication and runs the risk of having confusing overall system behavior. > If it isn't obvious how it should work with NWAM then perhaps the > answer is that it shouldn't. That doesn't sound right to me. >> 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? Neither. I mean that it works with the native features of OpenSolaris, including NWAM, rather than simply disabling all those features and doing its own private thing. "Well-integrated" means it works with the system rather than against it. -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ networking-discuss mailing list [email protected]
