> the confusion was less of an issue with the simplistic model that the
 > last word in the command line was the numeric address itself, but now
 > that we have thrown vanity-names, address pairs (for pointopoint
 > interfaces) and DNS into the mix, I think the simplest way forward is
 > to do this is:
 > 
 > # ipadm create-addr -a <ipsrc>[,<ipdst>] -i <interface> <addr_label>
 > 
 > i.e., make <addr_label> the mandatory "object" for all create-addr
 > invocations and allowing all of the following
 > 
 >   # ipadm create-addr -a 1.2.3.4/24 -i net0 addrone
 >   # ipadm create-addr -a myhost1/26 -i net1 myhost1
 >   # ipadm create-addr -a myhost2 -i net2 addrtwo
 >   # ipadm create-addr -a tladdr,traddr  -i tun0 tunaddr
 >   # ipadm create-addr -a 1.2.3.4,1.2.3.5  -i tun1 tunaddr2
 > 
 > the "myhost1" feels redundantly repeated twice in the second line, 
 > but the distinction between the 2 occurrences is that the first one
 > (with -a) is the hostname resolved through DNS when the address
 > is created, whereas the second occurrence is the alias for the 
 > address as known to libipadm.
 > 
 > Does that feel confusion-free and easy-to-use?

I fear there's still a significant chance for confusion.  In particular,
having a namespace that appears cosmetically similar to hostnames, and in
simple cases acts like a hostname, but is not actually a hostname and will
not be affected if the hostname->address mapping changes seems perilous.
Stepping back a little bit, have we really created something that's
noticeably better than logical interfaces?  For all their problems,
logical interfaces do make it clear what interface is associated with a
given address slot, and also do not clash with hostnames.

-- 
meem

Reply via email to