martin@xopen.co.uk (Martin Kirk) (06/27/91)
Submitted-by: martin@xopen.co.uk (Martin Kirk) Henry Spencer (henry@zoo.toronto.edu) writes > Why does it worry me that this list of related organizations does not > mention the IETF and the SNMP/MIB work -- the network-management > protocols and facilities that are in far wider use than any of the > above, with a far greater level of demonstrated interoperability. and Randall Atkinson (randall@Virginia.EDU) writes > Judging from comments below, they are still ignoring existing > practice in historical UNIX-derived systems in some cases. > If true, this is A Bad Thing. The intent was to convey the opposite impression. I think that wherever possible the work will reflect existing practise. > >Part of the motivation for this decision was recognition that the > >problem space is vast and that trying to attack it over too large a > >front was a suicidal manoeuvre. There was also an increased awareness > >of the related work of other organizations, such as the OSI Network > >Management Forum, the OSI Implementer's Workshop Network Management > >SIG, and X/Open. As this other work comes to fruition, it will be > >available for use by POSIX.7 and will likely solve some of the > >thornier problems, such as interoperability. > One would certainly hope that they are also tracking and taking > advantage of the good sized installed base that is already using SNMP > regularly. With the draft security extensions now published by the > IETF, SNMP has a good body of real-world experience. It would be best > if the POSIX.7 group tried to use that leverage to devise a good > standard. This isn't an OSI vs. TCP/IP thing; they should take > advantage of the experience of both groups. The list wasn't intended to be exhaustive or exclusive. The issue here is that P1003.7 is explicitly avoiding interoperability mechanisms at the moment. Nothing in the current P1003.7 work should preclude the use of OSI, TCP/IP, RPC, or a piece of wet string to achieve interoperability. Of course, some care needs to be taken to ensure that this actually is the case... At some point it will be necessary to prduce some specification of specific interoperability mechanisms, (presumably in the form of profiles), and at that time these should be taken from existing practice. > While network management is becoming better understood, it isn't > entirely a solved problem yet and I hope the POSIX.7 folks will be > careful in what they choose to standardise. The general model of using managed objects for management seems to work. I personally suspect that as it has really only been used in a network management environment there will probably be a need for extensions to bring it into the systems management arena. > > An obvious source of candidate management tasks can be found in the > > existing administrative command set on the systems around us, and it > > would be a perverse decision indeed to introduce gratuitous changes to > > the style of that interface. > Not only the style but also the content. Standardise what already > is historical practice and try to avoid inventing new features > without actual implementation and user experience. I agree. Both the form and the function should be preserved wherever possible. > >The Print Management work is based on the MIT Palladium printing > >system, which has the benefit of being well-aligned with the emerging > >ISO distributed printing standard, DIS 10164. > Palladium reportedly has an interface unlike those on historical > systems. I'd much rather see lp/lpr and lprm/lpstat be standardised > as user interfaces than something unfamiliar to virtually all of > the existing users. I understanding that a mapping of lp/lpr and lprm/lpstat into Palladium has been defined. This may be useful in providing for transition/compatibility/subsetting. > >Software Management has enjoyed a resurgence of interest within > >POSIX.7 over the last 6 months, with source material being drawn from > >DEC, HP, AT&T and Siemens-Nixdorf. > But is it based on historical systems ? > What kinds of tools are being standardised here ? Software installation and removal etc. The submisssions are based on existing vendors tools in this area. > >The third area, User Environment Management is a logical candidate for > >inclusion in the initial set of sub-projects. > What is being managed here besides user-addition ? > Could someone give examples maybe ? Addition/Deletion/Modification of users and groups. There is an interesting question here as to what the "user environment" should contain - skeleton startup files, certain environment variables, etc. The rationale for doing this first is that many other things that are managed have relationships to users, making this a common dependency for manyother areas. Also, for some reason, adding a user seems to be the universal example used in system management discussions. ====================================================================== The opinions expressed above are not necessarily those of anything or any one except me. ====================================================================== Martin Kirk m.kirk@xopen.co.uk Tel: +44 734 508311 ====================================================================== Volume-Number: Volume 24, Number 27