Cathy Zhou writes:
> >Provide the capability, and it will be abused.
> >  
> >
> Well, I don't know what we can do if privileged users do such things 
> only to confuse themselves.

I don't think it'd be a bad idea at all to have a document that
describes some suggested usages and some things that ought to be
avoided.  Perhaps it could focused on particular tasks: "using vanity
naming with Zones," "vanity naming with DR," "vanity naming in
clusters," and so on.  This should probably go into a blueprint or the
administrator's guide.

I agree that we're potentially handing people a lot of new rope.
If we know or find out any hazards, write them down.

> How to associate configuration with the alias? Does that mean 
> appliations will then access the link by opening the alias instead of 
> the link name? I guess the alias should be in the different namespace 
> from the link name. So that the open() API needs to indicate somehow 
> that it is openning an alias, not a link name? I might miss something 
> but I don't see how it going to work.

There are at least two ways to do this.  The one you're doing now
effectively _is_ that sort of alias -- yet another device node in the
tree somewhere that's named by the user.

Another way to do it is to provide a new feature that's analogous to
the ifAlias property in RFC 2863 (Interfaces MIB).  This doesn't
involve new device nodes or even potentially any kernel code.
Instead, you just provide a way for the administrator to assign and
retrieve an arbitrary string (e.g., "third wire from left" or "uplink
to transit") on a per-interface basis.

This allows administrators to assign meaningful notes on interfaces --
more so than can be jammed into the rather restrictive IP interface
naming conventions -- and gets out of the way of low-level
applications.  Applications that need to look up or use these new
strings will themselves need to iterate over the system's interfaces
in the usual way.

This is extremely useful for GUIs and the like.  It's a requirement if
you want to support the Standards-Track MIBs.  It's a common feature
and requirement for telecommunications gear.

The downside is that "simple" operations, such as netstat, snoop, and
ifconfig, see no obvious benefit.  They're most likely still stuck in
the world of e1000g0 and hme5.  And thus DR and Zones probably become
no easier to use.

I talked at some length with meem about this a long time ago.  The
short answer is that if you have a requirement to make the command
line tools easier and friendlier to use, then a high-level ifAlias
feature won't really get you there.  It'd still be nice to have, but
it's not the same thing.

-- 
James Carlson, KISS Network                    <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to