Sowmini.Varadhan at Sun.COM writes: > I don't want to get too caught up in the nomenclature here, > but my own initial instinct, like Jim's, was to club all > of it under ipadm. However, as becomes evident with property > management in comparison with the other commands considered, > it *is* true that the transport layer does not usually > target IP interfaces, just as the IP layer does not target > transport layer ports. It was for this reason that I split > the tools into "ipadm" (or "netadm" or "l3adm"??) and > transadm (or "xadm" or "ulpadm" or "l4adm"??).
The existing parameters tend to be stack-wide globals. There are a few historical oddities to the contrary, but they're generally like that. The IP ones don't target interfaces and the TCP ones don't target ports. I think the question here is: what sort of granularity do we need (or what objects will we operate on)? If we're not going to try to tune individual blades of grass, a single utility might well do it. If we have to go very fine grained, then I think "port" in one utility and "interface" in another may well be too restrictive. (E.g., setting a default MSS in TCP for a given remote subnet, or an IP TOS value to use based on a TCP port.) The other thing to consider is that if you're going to expose objects like that, you may have only a short life before you run straight into Crossbow's flowadm. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
