> so do we all concur on the proposal below?

I've tried for a week to like it, but I still dislike it, mostly because
it means objects do not have a consistent naming scheme (that is, the
identification scheme depends on the exact nature of the address object),
which is a pain both for the administrator and for layered tools that will
need to either work with the IP address or work with the label depending
on the situation.  Further, the hostname interlock doesn't really work
since the set of hostnames itself is dynamic -- e.g., admin X uses label
`foo' and then sometime later admin Y installs an unrelated system, gives
it a hostname of `foo' and populates DNS.

I won't try to sell you on my proposal again, but I will note that it does
provide consistent naming scheme for all address objects and does not run
afoul of hostname aliasing issues.

 > > 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.)

-- 
meem

Reply via email to