|
Replies:
18
-
Last Post:
Feb 21, 2006 8:38 PM
by: meem
|
|
|
Posts:
766
From:
US
Registered:
6/14/05
|
|
|
|
Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 12:39 AM
|
|
An updated version of the Vanity Naming and Nemo Unification design
document is now available at:
http://opensolaris.org/os/community/networking/uv-design.pdf
Comments are welcome. I've updated the document according to all
the review comments received. Below highlights some of the issues
raised during review and our proposed solutions:
a. The "DL_CAPAB_UNBOUNDED_PKT" capability
This has been changed to a DL_IOC_VLAN_CAPAB ioctl. The driver
will acknowledge this ioctl if it can handle the extra VLAN tag
bytes. This ioctl will not be used to address the Jumbo frame
issue which mentioned by Paul Jakma, since that problem should
be fixed by changing the driver to report the correct maximum
SDU in its DL_INFO_ACK.
b. show-aggr
Although Nicolas requested to provide an example of the new
show-aggr output, the show-aggr subcommand is different from
the other show-* subcommands because it displays more than one
level of objects (the aggregation and the aggregated links). It
is not optimal to have a "nested" table like today because we'd
like the output to be machine-parsing-friendly. We are still in
the discussion regarding this and the document will be updated
once we reach agreement.
c. discard-phys
This subcommand has been changed to delete-phys.
d. PPP devices (sppp0 etc.)
PPP devices will not be managed under softmac because they are
not associated with any hardware, are created on demands
and don't have any devfs nodes. That said, if it is necessary to
make PPP devices GLDv3 devices one day (for example, if we
decide to move the whole stack above TCP/IP away from DLPI),
the design does not prohibit the future changes to unify the PPP
devices under Nemo.
e. diskless boot
A new section 6.3.3 has been added to discuss the interaction
between diskless boot and vanity naming.
f. interrupt coalescing
Several reviewers raised their concerns regarding the performance
benefit of the "soft" interrupt coalescing. We will prototype this
and evaluate the performance impact, then decide what to do. For
now the document has been left as it was.
Thanks
- Cathy
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 2:31 PM
in response to: yun
|
|
Cathy Zhou wrote On 02/16/06 00:39,:
>An updated version of the Vanity Naming and Nemo Unification design
>document is now available at:
>
> http://opensolaris.org/os/community/networking/uv-design.pdf
>
Cathy,
Section 3.1.3 contains the statement:
Link names can be any valid style-1 DLPI provider name, which is a
composition of the driver name obeying the constraints identified in
the NOTES section of dlpi(7P)and a PPA number.
Since link names always have a style 1 device node, there are no PPA
numbers and the PPA number name syntax is not relevant. The text here
implies that there is a requirement of at least one trailing numeric
character in a link name; this requirement, if present, should be
removed and the text clarified. In principle, style 1 DLPI device
names never had the numeric suffix requirement but we codified the
practice in the belief that there could be applications that don't
support (or have never been tested with) style 1 devices and names.
Now, by defining a new name space and access method (libdlpi) the
FUD is gone and we should do the more flexible thing.
To put this in real terms, we should expect that in the future, people
will want to name their links after their zones, services, domains, etc.
and we should not create unnecessary restrictions here. (It's
unfortunate that we can't avoid the 15-byte length restriction due to
IFNAMSIZ, and Solaris's international character situation is too messed
up to allow non-ASCII characters.)
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
429
From:
GB
Registered:
6/15/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 2:36 PM
in response to: mditto
|
|
|
|
On 16 Feb 2006, at 22:31, Michael dot Ditto at Sun dot COM wrote:
> Since link names always have a style 1 device node, there are no PPA
> numbers and the PPA number name syntax is not relevant. The text here
> implies that there is a requirement of at least one trailing numeric
> character in a link name; this requirement, if present, should be
> removed and the text clarified. In principle, style 1 DLPI device
> names never had the numeric suffix requirement but we codified the
> practice in the belief that there could be applications that don't
> support (or have never been tested with) style 1 devices and names.
> Now, by defining a new name space and access method (libdlpi) the
> FUD is gone and we should do the more flexible thing.
>
Mike,
I made an attempt to remove the trailing digit from names when first
got Nemo up and running (an was thus able to name links arbitrarily).
The Solaris IP stack has the need for the trailing digit fairly deeply
ingrained. It will take significant work to remove that requirement.
Paul
--
Paul Durrant
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 2:49 PM
in response to: pdurrant
|
|
Paul Durrant wrote On 02/16/06 14:36,:
> I made an attempt to remove the trailing digit from names when first
>
>got Nemo up and running (an was thus able to name links arbitrarily).
>The Solaris IP stack has the need for the trailing digit fairly deeply
>ingrained. It will take significant work to remove that requirement.
>
>
We can fix the problems in IP in a separate project if necessary.
If IP really chokes on some link names, ifconfig (or IP itself)
should reject them, but libdlpi/dladm shouldn't introduce such
restrictions anew. Remember that things other than IP access the
link layer too.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 2:49 PM
in response to: pdurrant
|
|
Paul Durrant writes:
> I made an attempt to remove the trailing digit from names when first
> got Nemo up and running (an was thus able to name links arbitrarily).
> The Solaris IP stack has the need for the trailing digit fairly deeply
> ingrained. It will take significant work to remove that requirement.
It's much more than that. All other systems use that same
<name><digits> naming convention, so Solaris is hardly alone in the
matter.
Perhaps more importantly, nothing really is gained by going to a world
where links don't end in digits. It doesn't fix any problem.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 3:00 PM
in response to: carlsonj
|
|
James Carlson wrote On 02/16/06 14:49,:
>It's much more than that. All other systems use that same
><name><digits> naming convention, so Solaris is hardly alone in the
>matter.
Linux doesn't require digits and in fact quite sensibly uses the
interface name "lo" for loopback.
>Perhaps more importantly, nothing really is gained by going to a world
>where links don't end in digits. It doesn't fix any problem.
There will be problems when admins are required to make up names for
virtual links that correspond to their zones and virtual machine
domains and are forced to arbitrarily transform the names they use in
one space when creating parallel objects in another space. (This will
become more obvious with the Crossbow project.)
Instance numbers as an administrative interface are so 20th century.
"Vanity naming" should be about meaningful administrator-chosen
labels, not about mirroring internal IP data structures.
-=] Mike [=
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 3:06 PM
in response to: mditto
|
|
Michael dot Ditto at Sun dot COM writes:
> Instance numbers as an administrative interface are so 20th century.
> "Vanity naming" should be about meaningful administrator-chosen
> labels, not about mirroring internal IP data structures.
Digging up the same thread we had a couple of years ago about this
very topic might be helpful. We were able to find several
applications (I believe GateD was one of them) that would fall over
dead if interfaces didn't have the expected naming conventions.
I still don't get it. I see no point to doing this because the field
itself is far too inflexible to go where you want -- there's no i18n,
no expectation of embedded spaces, and no room to write anything
comprehensible. What's the point?
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 8:37 PM
in response to: carlsonj
|
|
> I still don't get it. I see no point to doing this because the field
> itself is far too inflexible to go where you want -- there's no i18n,
> no expectation of embedded spaces, and no room to write anything
> comprehensible. What's the point?
Emphatically agreed. Let's not burn our resources on this.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 17, 2006 3:44 PM
in response to: meem
|
|
peter dot memishian at Sun dot COM wrote:
> Emphatically agreed. Let's not burn our resources on this.
Unless you're saying you don't want to spend even the time to discuss
it, I don't know what resources you mean. I'm talking about a fairly
small documentation change, and maybe removing one or two lines of code,
if they even have been written already. (IP itself already fails fairly
cleanly when there is no numeric suffix in an interface name.)
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 18, 2006 1:45 AM
in response to: mditto
|
|
> > Emphatically agreed. Let's not burn our resources on this.
>
> Unless you're saying you don't want to spend even the time to discuss
> it, I don't know what resources you mean. I'm talking about a fairly
> small documentation change, and maybe removing one or two lines of code,
> if they even have been written already. (IP itself already fails fairly
> cleanly when there is no numeric suffix in an interface name.)
If we're not going to make IP work, and we're not going to test that other
DLPI-based applications work, then I don't see any point in removing the
requirement for a trailing digit. One of the philosophies of Clearview is
to make the administrative model more consistent. Being able to create
link names that only work with specific DLPI consumers is a step away from
that -- and a pointless step, given the other higher-level restrictions on
the format of DLPI names (e.g., allowing special tokens such as `:' would
prove disastrous for IP).
All that said, there is nothing in the Vanity Naming administrative model
that requires the use of a trailing digit -- if the restriction needs to
be lifted in the future, Vanity Naming will certainly not prove an
impediment. But for all of the reasons already stated, we have no plans
whatsoever to take this tangential (and IMHO misguided) work on as part of
Clearview.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 21, 2006 5:54 PM
in response to: meem
|
|
Peter dot Memishian at sun dot com wrote On 02/18/06 01:45,:
>If we're not going to make IP work, and we're not going to test that other
>DLPI-based applications work, then I don't see any point in removing the
>requirement for a trailing digit. One of the philosophies of Clearview is
>to make the administrative model more consistent. Being able to create
>link names that only work with specific DLPI consumers is a step away from
>that -- and a pointless step, given the other higher-level restrictions on
>the format of DLPI names (e.g., allowing special tokens such as `:' would
>prove disastrous for IP).
>
>
Consistency is great, but that doesn't justify piling crud on top of
some otherwise clean parts of the system to match the height of the crud
that already exists in another spot. Even just spreading it around
evenly isn't very good, it certainly doesn't help the person who comes
along after you who is willing to shovel it away entirely as long as
it's only in one place.
As for testing, the change I suggest reduces the testing required (if you
add code to enforce this arbitrary restriction, you have to test it... if
it's not there, there's nothing to test.) There is no effect on the
amount of non-IP testing required or the likelihood of problems in non-IP
code.
>All that said, there is nothing in the Vanity Naming administrative model
>that requires the use of a trailing digit -- if the restriction needs to
>be lifted in the future, Vanity Naming will certainly not prove an
>impediment.
>
I'm not so sure that's true. By documenting the restriction you are
inviting applications to write code that depends on it, and getting us
stuck right back where we were, unable to improve.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 20, 2006 11:56 AM
in response to: mditto
|
|
Mike Ditto writes:
> peter dot memishian at Sun dot COM wrote:
> > Emphatically agreed. Let's not burn our resources on this.
>
> Unless you're saying you don't want to spend even the time to discuss
> it, I don't know what resources you mean.
No, it's not that, though it has already been discussed extensively
more than once.
The "resources" involved would be finding and repairing all the
applications that are damaged by the change. There are still some
applications known to be damaged by "unusual" interface names such as
"e1000g" -- because they were erroneously assuming that the _first_
digit in the interface name would be the instance number (meaning that
these broken applications see driver name "e" and instance "1000" and
are unusable on platforms with that driver).
We would be adding others such as GateD and very likely some support
applications to that carnage by walking away from the long-standing
BSD tradition for interface naming. I see no point. Using "foobar"
as a name is to me no clearer or more usable than using "foobar0."
Worse, doing this would mean that applications using Style 2 would be
unable to describe these interfaces at all. We'd be introducing
another wart to the implementation.
There's an extensive downside and no benefit I can see.
> I'm talking about a fairly
> small documentation change, and maybe removing one or two lines of code,
> if they even have been written already. (IP itself already fails fairly
> cleanly when there is no numeric suffix in an interface name.)
It's not a matter of the small code change or the documentation.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 21, 2006 6:07 PM
in response to: carlsonj
|
|
James Carlson wrote On 02/20/06 11:56,:
>The "resources" involved would be finding and repairing all the
>applications that are damaged by the change. There are still some
>applications known to be damaged by "unusual" interface names such as
>"e1000g" -- because they were erroneously assuming that the _first_
>digit in the interface name would be the instance number (meaning that
>these broken applications see driver name "e" and instance "1000" and
>are unusable on platforms with that driver).
>
That's why I want to change this now, while we can. Applications
that are changed to use libdlpi will not have such assumptions
built into them if we make it clear in the documentation what is
and isn't legitimate for the application to assume.
>We would be adding others such as GateD and very likely some support
>applications to that carnage by walking away from the long-standing
>BSD tradition for interface naming. I see no point. Using "foobar"
>as a name is to me no clearer or more usable than using "foobar0."
>
>
That's an issue for IP interfaces only and I agree there may be software
that has trouble, which would restrict users to using only conventional
interface names with IP if they want to use such software.
>Worse, doing this would mean that applications using Style 2 would be
>unable to describe these interfaces at all. We'd be introducing
>another wart to the implementation.
>
No, those applications can not use vanity names anyway. They are not
affected by my suggestion.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 21, 2006 7:11 PM
in response to: mditto
|
|
On Fri, 2006-02-17 at 15:44 -0800, Mike Ditto wrote:
> Unless you're saying you don't want to spend even the time to discuss
> it, I don't know what resources you mean. I'm talking about a fairly
> small documentation change, and maybe removing one or two lines of code,
> if they even have been written already. (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? If the administrator is
somehow clued in at that point that the interface name is invalid, he'll
have to go back and rename the interface. What would be the point of
frustrating the customer in this way?
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.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 21, 2006 8:01 PM
in response to: seb
|
|
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,045
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 21, 2006 8:38 PM
in response to: mditto
|
|
> 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.
But we *have* taken it into account -- there is nothing in our design that
requires the trailing digit -- we just have a policy enforcement of an
existing rule.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 2:52 PM
in response to: mditto
|
|
Michael dot Ditto at sun dot com writes:
> practice in the belief that there could be applications that don't
> support (or have never been tested with) style 1 devices and names.
> Now, by defining a new name space and access method (libdlpi) the
> FUD is gone and we should do the more flexible thing.
I _strongly_ disagree. There's no point to doing this.
> To put this in real terms, we should expect that in the future, people
> will want to name their links after their zones, services, domains, etc.
> and we should not create unnecessary restrictions here. (It's
> unfortunate that we can't avoid the 15-byte length restriction due to
> IFNAMSIZ, and Solaris's international character situation is too messed
> up to allow non-ASCII characters.)
I do agree that users need to have more flexible ways of identifying
and referring to interfaces. This is where something like ifAlias
comes in: we could provide a way to attach an arbitrary string to an
interface for administrative purposes.
Why force users to use something silly like "ord02a1" when they could
use "backup link to Chicago?"
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
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
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 3:17 PM
in response to: carlsonj
|
|
James Carlson wrote On 02/16/06 14:52,:
>I do agree that users need to have more flexible ways of identifying
>and referring to interfaces. This is where something like ifAlias
>comes in: we could provide a way to attach an arbitrary string to an
>interface for administrative purposes.
>
>Why force users to use something silly like "ord02a1" when they could
>use "backup link to Chicago?"
If that could be the *only* name that the administrator needs to
do everything with the link, that would be great. But ifAlias still
requires some "fundamental" label for the link and -- especially for
completely virtual links constructed by the user -- those should be
freely defined by the administrator.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
|
|
|
|
Re: Updated Clearview Vanity Naming and Nemo
Unification design document
Posted:
Feb 16, 2006 4:05 PM
in response to: carlsonj
|
|
On Thu, 16 Feb 2006, James Carlson wrote:
> and referring to interfaces. This is where something like ifAlias
> comes in: we could provide a way to attach an arbitrary string to
> an interface for administrative purposes.
>
> Why force users to use something silly like "ord02a1" when they could
> use "backup link to Chicago?"
Like:
# sh interface ip.tun0
Interface ip.tun0 is up, line protocol detection is disabled
Description: Punchin interface
index 8 metric 0 mtu 1366 <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>mtu6 0
inet 129.150.121.31/32 pointopoint 129.156.90.55
?
;)
The description string does not per se have to go in kernel if
there's some kind of userspace thingy ('zebra' or the GNOME-related
NetworkManager) keeping state.
regards,
--
Paul Jakma paul at clubi dot ie paul at jakma dot org Key ID: 64A2FF6A
Fortune:
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
-- Doug Gwyn
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
