On 19/07/09 04:49 AM, Sowmini.Varadhan at Sun.COM wrote: >> > but why do we need to auto-assign? Why can't we mandate that the >> > object provided to "create-addr" must be of the form <interface>/<string>, >> > where <string> is constructed from some well-defined set of chars (e.g., >> > [a-z][A-Z][0-9]'-') >> > > On (07/17/09 13:45), Peter Memishian wrote: > >> Because then we're back in the soup of forcing the administrator to name >> all their address objects with names that are not hostnames. Yes, the >> "<ifname>/" prefix helps but I would expect that most administrators are >> still going to use the hostname. Further, given that these objects are >> not necessarily tied to any specific address (e.g, in the case of >> non-static addresses), it's nice to have a facility in the system for >> naming them automatically. >> > > I don't think that thrusting some system-generated > quasi-logical-interface-name > like bge0/1001 upon the audience is a good idea either.. stepping back a bit, > > 1. the simplest way to identify a static address (on a non-point-to-point > interface) is by the value of the address itsef, e.g., bge0/1.2.3.4 > > 2. it's the point-to-point, and non-static (i.e., dhcp and ipv6 addrconf) > addresses that could use a "label" mnemonic to make them easier to > identify from the command line > > 3. we want to avoid conflicts with the namespace used by hostname resolvers > or the kernel's logical interfaces. >
The only way to achieve (3) is for the namespace to be composed of names that do not use the ASCII alphabet. Further, I'd recommend using a different separator than "/", especially if there is a number. Seeing "bge0/3" written is more likely to conjure up thoughts in people's heads of the netmask being 0xe0000000. In addition, any tool (such as ipfilter) that allows you to use "<nic>/<something>" would be instantly incompatible with this design. So, at the very least you need a new separator. Darren -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/brussels-dev/attachments/20090731/37282e10/attachment.html>
