Peter Memishian writes: > > > Why can't ipadm have or be given a generic-enough name to cover the > > transports as well? > > I worry about the command becoing a garbage can. The natural objects for > ipadm are IP addresses and IP interfaces (and perhaps IP logical interface > IDs). Adding transport port numbers to the mix, along with the union of > all administrative objects/actions related to UDP, TCP, SCTP, RDS, et al. > seems questionable to me.
Does RDS have anything at all to do with TCP/IP? That aside, I think we've got a fair bit to cover here, and we can either turn /usr/sbin into a trashcan by flooding it with *adm utilities, each with a tiny view of the Universe, or we can put natural groupings together, and live with the complexity there. I don't think the complexity can be eliminated, only moved around. In this case, I see supporting the TCP/IP family of transport and network layer protocols in one place as a good thing, just as dladm is a good way to handle all of the datalink layer protocols. We don't want to have wifiadm, so why should there be tcpadm? -- 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
