jsh@usenix.org (Jeffrey S. Haemer) (10/21/89)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.7: System Administration Update
Steven J. McDowall <sjm@mca.mn.org> reports on the July 10-14, 1989
meeting, in San Jose, California:
War and Remembrance - How I survived a Posix Meeting
Listen closely to this tale of wonder and bewilderment and hope that
you shall never have to face such horrors as I. Yes, I was there
when, in a flurry of activity, the 1003.7 committee elected Steven
Carter to the chair. To show he was a good choice, Carter immediately
sat on the chair to which he'd been elected. This was swiftly
followed by the election of Vice-chairs Martin Kirk and Dave Hinnant
(though I shall speculate not on what vices they may have perpetrated
on those chairs); Mark Colburn, Secretary (owing to a proven ability
to take dictation lying on a pool-side sun bed); and their honors Bob
Bauman and Shoshana O'Brien, Technical Editors.
You may sense that I feel few exciting things happened in San Jose.
Correct. I wish this group would get into some real fights, like
other groups. Interoperability may prove our only hope. Still,
progress is progress, however uncontentious. Here's what else seemed
to me to be important.
1. Language Independence
The group voted, nearly unanimously, that the country of
Language should be independent. We were uncertain about where,
precisely, it might be, but tentatively put it near Borneo.
We chose to use ASN.1 ("Abstract Syntax Notation - 1") as our
internal notation for data structures. The group also appointed
me representative to the 1003.1 language-bindings group to watch
what those pursuers of knowledge are doing in this area.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.7: System Administration
- 2 -
2. Interoperability
X/Open continues to push this into the foreground. Luckily for
us, they also continue to help us understand what it entails.
Group consensus holds that interoperability is within the
purview of 1003.7. What we're still uncertain of is how far
down we should standardize; only through the application layer?
down to the packet layer?
For example, a standard application-layer protocol insuring
interoperability might require that certain Application Program
Interface (API) calls be available, with given arguments and
results, but say nothing about how those calls are made. In
contrast, a transport-level protocol might require that the
information be fed into the API will be in a pseudo-ASN.1 format
to help in non-homogeneous networks. A still lower level
protocol might detail the exact packet structure, including
ASN.1 format for the object data, to prevent foreign machines in
a non-homogeneous network from throwing out otherwise
unrecognizable packets.
Most committee members have strong, idiosyncratic ideas about
this subject and the issue is certain to re-surface in Brussels.
We need input on this from the community at large. Where do YOU
think a standards organization like the IEEE should draw the
line in ensuring interoperability?
[Editor's note -- This is not a rhetorical question. Things you
do in the future may be affected by decisions P1003.7 makes in
this arena. If you have an opinion on this subject, speak up.]
As an aside, the current X/OPEN representative, Jim Oldroyd of
the Instruction Set, Ltd., who has really helped the group a
great deal in this area, may not attend the next 1003.7 meeting.
We think this would be a real loss, and hope that X/OPEN and his
employer find a way to arrange for him to go.
3. Misc.
Some progress was made in doing the ASN.1 syntax for a few of
the basic objects the committee decided on for phase I of the
standard. Everyone is discovering that defining such objects
(File Systems, Devices, Spools, etc.) in a non-ambiguous way
using a meta-language like ASN.1 might not be as easy as we
first thought. Live and learn, eh?
September 1989 Standards Update IEEE 1003.7: System Administration
Volume-Number: Volume 17, Number 43jsh@usenix.org (Jeffrey S. Haemer) (01/06/90)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.7: System Administration Update
Steven J. McDowall <sjm@mca.mn.org> reports on the October 16-20, 1989
meeting in Brussels, Belgium:
Background
Joe Friday would say, "Just the facts, ma'am." And that's the way I
feel. The facts are that I'm sick, it's Thanksgiving, I am going to
London for two weeks tomorrow, and 1003.7 is defining a standard way
to administer POSIX systems.
Now, almost everyone agrees that 1003.7 should deal with networks, not
just isolated systems. To wit, it would be nice if I could administer
all the machines in a network from a single machine with simple
commands. For example, to add a user to all machines in the domain
"mn.org", all I should need to do is issue a command like "adduser -d
mn.org -options -parameters username". The question is, without any de
facto standard already in place to adopt, how can we achieve this?
The Approach
This is important, so pay attention. Because the major goal of 1003.7
is to create a standard way to manage a set of objects, the group has
decided to take an object-oriented approach. Our idea is to begin by
creating a list of objects to manage, then to follow that by defining
the set of commands to manage each object. This approach is novel for
both system administration and POSIX. It will probably require more
work on the front end to define the objects, their attributes, and
their relationships, than to define the actual command structure to
support and manipulate them. Whether this approach will work remains
to be seen.
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.7: System Administration
- 2 -
The Meeting
The meeting was boring. To put it bluntly, the week was simply a work
week. Objects (and sub-objects) were defined and discussed in detail,
then put in the draft. Little got done on the first and last days,
due to EEC formalities, which left us with three working days instead
of the normal four and a half. Attendance was pretty dramatically
reduced, too. About half the normal North Americans showed up,
probably because of the location, and only one (yes one...) new
European came even though we were meeting in Europe. Oh well, except
for my having had my passport stolen, it was a good chance to see
Belgium.
Concerns
1. The process is taking a long time to move ahead, both because of
the difficulty involved and because we seem to attract less
manpower than many other groups. Moreover, since we're taking a
radical approach, it takes extra time to teach the ideas to
anyone new that does come.
2. System administration doesn't have the glamour of some of the
other areas being standardized. As the Rodney Dangerfield of
POSIX, 1003.7 gets no respect.
3. The notation we're using to define our objects is ASN.1. "Why
ASN.1?" you ask. Simply because it's a standardized meta-
language to describe abstract data types. The feeling was that
this would help make the whole package more suitable for
interoperability. I bring this up because there's some movement
throughout 1003 to re-do all data structures in a new meta-
language created by some of the people working on language-
independence. Not only would this require that we go back and
re-do our definitions, but I also think ISO will only allow the
use of standardized data-languages in their standards. Does
anyone out there know if there is such an ISO restriction? If
so, it's important for 1003 as a whole, not just for dot seven.
4. Currently, almost all working-committee members are from
vendors. IBM, DEC, HP, AT&T, and others are well-represented.
A few interested parties, like OSF and /sys/admin. are there as
well, but as far as I can tell, there isn't one real user. By
"real user" I mean someone who does nothing but administer a
system. All of us are connected somehow with creating an
administrable system or getting paid to do so. Of course, I
should make clear that we all have to administer systems of our
own, so we're not simply an ivory tower group with no real
December 1989 Standards Update IEEE 1003.7: System Administration
- 3 -
experience, but representation is still grossly unbalanced.
5. Finally, there's been a loss of focus on interoperability
directly attributable to the loss of our X/OPEN representative,
Jim Oldroyd. Jim was well respected and made many valuable
contributions, but can no longer attend our meetings. As the
X/OPEN representative, he was very concerned with multi-vendor
environments, and was a major force in helping us focus on and
ensure interoperability. I am not saying that no one else on
the committee cares about the issue, but it does seem to be
being pushed aside in a spirit of, "I think we shouldn't have
any interoperability problems if we do this, so let's do it and
worry about it later on." Jim had helped provide a more
positive, direct approach of determining up front what would be
needed for true interoperability. If X/OPEN is still interested
in System Administration, and in making sure the 1003.7 standard
includes provisions for interoperability, we could still use
their help.
December 1989 Standards Update IEEE 1003.7: System Administration
Volume-Number: Volume 18, Number 5