> > * The options will be different and often non-overlapping for > > the different scenarios. For instance, the -e, -i, -a, -b, > > and -m options to connect are WiFi-specific. > > But you can always tell from context, from the interface name, which > options should apply.
Post-Clearview, the link name will be arbitrary (whatever the administrator wants -- of course, the administrator can follow a convention that may make it easy to tell that it's a WiFi link). Regardless, it's still alphabet soup -- with increasingly unintuitive option letters (ls -E, anyone?) > I think we might, yes. Consider a putative Ethernet + VLAN + EAP > technology, and imagine a network that offers two VLANs, one being SWAN > and requiring user authentication, and the other being an open > connection to the Internet, for guests, say. Then we might have > multiple networks to discover. With Ethernet + VLAN, each VLAN is modeled as a separate link -- so there's still no discovery (you'd just "connect" on the appropriate link) With only one link to use, filtering and prioritization make little sense. As an aside, VLAN's aren't really "discovered" (at least, I'm not aware of an easy way to do it). > Today, of course, these verbs apply only to wireless networking, which > also seems to make the -wifi obnoxious: it's obvious and redundant. I don't think it's as black-and-white as you're trying to make it. There are pros and cons to both models. I hope I've pointed out some of the reasons why we're proposing having dedicated commands. > I meant something fuzzier; I meant "virtual interface" as in having > multiple interface names that can be used with ifconfig/dladm but each > intended for different ESSIDs/VLANs/whatever logical network notion. Right, that's the way we'd model it -- this allows it to be easily managed at higher levels of the stack. -- meem _______________________________________________ networking-discuss mailing list [email protected]
