> > 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.
So why don't we just require a label to be supplied for the cases identified
in #2, and in those cases, if the label conflicts with a hostname,
we return an error ("pick another label"). I don't think people would
intuitively want to pick an entry that's also resolved as a hostname for
these address types anyway.
For static addresses on non-point-to-point interfaces, the "label" is
just <interface>/<numeric address>. (Yes, this is clumsy for IPv6,
but other than getting into resolver-soups, I don't see a solution for
that.)
--Sowmini
