home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0026.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  5.2 KB  |  116 lines
  1. Submitted-by: martin@xopen.co.uk (Martin Kirk)
  2.  
  3. Henry Spencer (henry@zoo.toronto.edu) writes
  4.  
  5. > Why does it worry me that this list of related organizations does not
  6. > mention the IETF and the SNMP/MIB work -- the network-management
  7. > protocols and facilities that are in far wider use than any of the
  8. > above, with a far greater level of demonstrated interoperability.
  9.  
  10. and Randall Atkinson (randall@Virginia.EDU) writes
  11.  
  12. >  Judging from comments below, they are still ignoring existing
  13. > practice in historical UNIX-derived systems in some cases.  
  14. > If true, this is A Bad Thing.
  15.  
  16. The intent was to convey the opposite impression. I think that
  17. wherever possible the work will reflect existing practise.
  18.  
  19. > >Part of the motivation for this decision was recognition that the
  20. > >problem space is vast and that trying to attack it over too large a
  21. > >front was a suicidal manoeuvre.  There was also an increased awareness
  22. > >of the related work of other organizations, such as the OSI Network
  23. > >Management Forum, the OSI Implementer's Workshop Network Management
  24. > >SIG, and X/Open.  As this other work comes to fruition, it will be
  25. > >available for use by POSIX.7 and will likely solve some of the
  26. > >thornier problems, such as interoperability.
  27.  
  28. >   One would certainly hope that they are also tracking and taking
  29. > advantage of the good sized installed base that is already using SNMP
  30. > regularly.  With the draft security extensions now published by the
  31. > IETF, SNMP has a good body of real-world experience.  It would be best
  32. > if the POSIX.7 group tried to use that leverage to devise a good
  33. > standard.  This isn't an OSI vs. TCP/IP thing; they should take
  34. > advantage of the experience of both groups.
  35.  
  36. The list wasn't intended to be exhaustive or exclusive. The issue here
  37. is that P1003.7 is explicitly avoiding interoperability mechanisms at
  38. the moment. Nothing in the current P1003.7 work should preclude the
  39. use of OSI, TCP/IP, RPC, or a piece of wet string to achieve
  40. interoperability. Of course, some care needs to be taken to ensure that
  41. this actually is the case... At some point it will be necessary to
  42. prduce some specification of specific interoperability mechanisms,
  43. (presumably in the form of profiles), and at that time these should be
  44. taken from existing practice.
  45.  
  46. >   While network management is becoming better understood, it isn't
  47. > entirely a solved problem yet and I hope the POSIX.7 folks will be
  48. > careful in what they choose to standardise.
  49.  
  50. The general model of using managed objects for management seems to
  51. work. I personally suspect that as it has really only been used in a
  52. network management environment there will probably be a need for
  53. extensions to bring it into the systems management arena.
  54.  
  55. > >  An obvious source of candidate management tasks can be found in the
  56. > > existing administrative command set on the systems around us, and it
  57. > > would be a perverse decision indeed to introduce gratuitous changes to
  58. > > the style of that interface.  
  59.  
  60. > Not only the style but also the content.  Standardise what already
  61. > is historical practice and try to avoid inventing new features
  62. > without actual implementation and user experience.
  63.  
  64. I agree. Both the form and the function should be preserved wherever
  65. possible.
  66.  
  67. > >The Print Management work is based on the MIT Palladium printing 
  68. > >system, which has the benefit of being well-aligned with the emerging 
  69. > >ISO distributed printing standard, DIS 10164.  
  70.  
  71. > Palladium reportedly has an interface unlike those on historical
  72. > systems.  I'd much rather see lp/lpr and lprm/lpstat be standardised
  73. > as user interfaces than something unfamiliar to virtually all of
  74. > the existing users.
  75.  
  76. I understanding that a mapping of lp/lpr and lprm/lpstat into
  77. Palladium has been defined. This may be useful in providing for
  78. transition/compatibility/subsetting.
  79.  
  80. > >Software Management has enjoyed a resurgence of interest within 
  81. > >POSIX.7 over the last 6 months, with source material being drawn from 
  82. > >DEC, HP, AT&T and Siemens-Nixdorf.
  83.  
  84. > But is it based on historical systems ?  
  85. > What kinds of tools are being standardised here ?
  86.  
  87. Software installation and removal etc. The submisssions are based on
  88. existing vendors tools in this area.
  89.  
  90. > >The third area, User Environment Management is a logical candidate for
  91. > >inclusion in the initial set of sub-projects.  
  92.  
  93. > What is being managed here besides user-addition ?  
  94. > Could someone give examples maybe ?
  95.  
  96. Addition/Deletion/Modification of users and groups. There is an
  97. interesting question here as to what the "user environment" should
  98. contain - skeleton startup files, certain environment variables, etc.
  99. The rationale for doing this first is that many other things that are
  100. managed have relationships to users, making this a common dependency
  101. for manyother areas. Also, for some reason, adding a user seems to be
  102. the universal example used in system management discussions.
  103.  
  104. ======================================================================
  105. The opinions expressed above are not necessarily those of anything or
  106. any one except me.
  107. ======================================================================
  108.  
  109. Martin Kirk    m.kirk@xopen.co.uk        Tel: +44 734 508311
  110.  
  111. ======================================================================
  112.  
  113.  
  114. Volume-Number: Volume 24, Number 27
  115.  
  116.