P1003.7 comments

[Martin Kirk]

Submitted-by: martin at xopen.co.uk (Martin Kirk)

Henry Spencer (henry at 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 at 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 at xopen.co.uk		Tel: +44 734 508311

======================================================================


Volume-Number: Volume 24, Number 27