home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0024.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  3.2 KB  |  83 lines
  1. Submitted-by: randall@Virginia.EDU (Randall Atkinson)
  2.  
  3. In article <1991Jun25.214723.7644@uunet.uu.net>,
  4.   Peter Collinson <pc@hillside.co.uk> writes:
  5. >Submitted-by: pc@hillside.co.uk (Peter Collinson)
  6. >
  7. >USENIX Standards Watchdog Committee
  8. >Stephen R. Walli <stephe@usenix.org>, Report Editor
  9. >1003.7: System Administration
  10. >
  11. >Martin Kirk <m.kirk@xopen.co.uk> reports on the April 15-19,
  12. >1991 meeting in Chicago, IL:
  13.  
  14. >Inevitably this change of direction led to charges that the group was
  15. >inventing hand-over-fist, rather than following the ``traditional''
  16. >standards model of codifying existing practice.  
  17.  
  18.   Judging from comments below, they are still ignoring existing
  19. practice in historical UNIX-derived systems in some cases.  
  20. If true, this is A Bad Thing.
  21.  
  22. >Part of the motivation for this decision was recognition that the
  23. >problem space is vast and that trying to attack it over too large a
  24. >front was a suicidal manoeuvre.  There was also an increased awareness
  25. >of the related work of other organizations, such as the OSI Network
  26. >Management Forum, the OSI Implementer's Workshop Network Management
  27. >SIG, and X/Open.  As this other work comes to fruition, it will be
  28. >available for use by POSIX.7 and will likely solve some of the
  29. >thornier problems, such as interoperability.
  30.  
  31.   One would certainly hope that they are also tracking and taking
  32. advantage of the good sized installed base that is already using SNMP
  33. regularly.  With the draft security extensions now published by the
  34. IETF, SNMP has a good body of real-world experience.  It would be best
  35. if the POSIX.7 group tried to use that leverage to devise a good
  36. standard.  This isn't an OSI vs. TCP/IP thing; they should take
  37. advantage of the experience of both groups.
  38.  
  39.   While network management is becoming better understood, it isn't
  40. entirely a solved problem yet and I hope the POSIX.7 folks will be
  41. careful in what they choose to standardise.
  42.  
  43. >  An obvious source of candidate management tasks can be found in the
  44. > existing administrative command set on the systems around us, and it
  45. > would be a perverse decision indeed to introduce gratuitous changes to
  46. > the style of that interface.  
  47.  
  48. Not only the style but also the content.  Standardise what already
  49. is historical practice and try to avoid inventing new features
  50. without actual implementation and user experience.
  51.  
  52. >The Print Management work is based on the MIT Palladium printing 
  53. >system, which has the benefit of being well-aligned with the emerging 
  54. >ISO distributed printing standard, DIS 10164.  
  55.  
  56. Palladium reportedly has an interface unlike those on historical
  57. systems.  I'd much rather see lp/lpr and lprm/lpstat be standardised
  58. as user interfaces than something unfamiliar to virtually all of
  59. the existing users.
  60.  
  61. >Software Management has enjoyed a resurgence of interest within 
  62. >POSIX.7 over the last 6 months, with source material being drawn from 
  63. >DEC, HP, AT&T and Siemens-Nixdorf.
  64.  
  65. But is it based on historical systems ?  
  66. What kinds of tools are being standardised here ?
  67.  
  68. >The third area, User Environment Management is a logical candidate for
  69. >inclusion in the initial set of sub-projects.  
  70.  
  71. What is being managed here besides user-addition ?  
  72. Could someone give examples maybe ?
  73.  
  74. Randall Atkinson
  75. randall@Virginia.EDU
  76.  
  77.  
  78.  
  79.  
  80.  
  81. Volume-Number: Volume 24, Number 25
  82.  
  83.