Sebastien Roy wrote On 02/21/06 19:11,:
>>(IP itself already fails fairly
>>cleanly when there is no numeric suffix in an interface name.)
>>
>Mike, how will it be clean?  The administrator will create a link, and
>then sometime later attempt to plumb an IP interface on that link.  The
>latter will fail with some error, and the administrator will be left
>wondering what is wrong with the system?

That is the correct behavior given the limitations of the IP
implementation.  It shouldn't be an error to have a device on your
system that IP can't use.  You don't get an error when you plug in a
sound card, but you do get one if you "ifconfig audio plumb".

One could consider some usability improvements and I wouldn't argue
against them:

  Mention in the dladm documentation that there are additional
  constraints on link names depending on what software will use them,
  specifically IP interface names must conform to the format ...

  Make the error message printed by ifconfig more explanatory (it
  currently says something like "ioctl(SIOCSLIFNAME) - invalid argument"
  -- instead it could say something like 'ifconfig: "thisnic" is not a
  legal interface name; see ifconfig(1M)').

  Develop task-oriented system management tools that hide all the
  internal steps for a task like adding and configuring a link for IP
  use, so that the user interface validates each parameter early,
  interactively, and with user-friendly explanations of the limitations.


>If we decide at some point that such vanity names would be useful, then
>I would argue that we should at least ensure that all of our software
>can handle such a change to reduce customer confusion.  If we could do
>the same for 3rd party software, then we should do that as well.
>However, I don't yet see how the benefit of going this extra step
>outweighs the drawbacks that have been discussed.

I entirely concede that the current project does not see the value of
link names less restrictive than what IP currently supports and that the
project should not be expected to take on additional work to provide
features that have only hypothetical value.  But that doesn't excuse the
project from taking into account future uses of the infrastructure it
creates and avoiding mistakes that will prevent someone else from
innovating in the future.

                                        -=] Mike [=-



_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to