Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/archive

Internet Message Format | 1994-03-07 | 84KB

From [e-mail]  Mon Feb 14 15:19:17 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdgj05705; Mon, 14 Feb 94 15:19:17 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdgj20852; Mon, 14 Feb 94 15:18:51 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA16267; Mon, 14 Feb 94 12:19:32 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id MAA20991 for [e-mail]; Mon, 14 Feb 1994 12:18:40 -0800
Xref: majipoor.cygnus.com comp.std.unix:264
From: [e-mail] (Sean Eric Fagan)
Newsgroups: comp.std.unix
Subject: Policy and Guidelines for comp.std.unix
Organization: UUNET Communications Services
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 14 Feb 1994 12:16:41 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sean Eric Fagan)

This is a policy statement for comp.std.unix.

This is Volume 33 of comp.std.unix.
These volumes are purely for administrative convenience.
Feel free to continue any previous discussion or to start new ones.

Subject: Topic.

The USENET newsgroup comp.std.unix, also known as the mailing list
[e-mail], is for discussions of standards related to
the UNIX operating system, particularly of IEEE P1003, or POSIX,
including IEEE 1003.1, 1003.2, etc.

Other related standards bodies and subjects include but are not limited to
    IEEE 1201 and IEEE 1238,
    ISO/IEC JTC1 SC22 WG15 (the ISO and IEC version of POSIX),
    the U.S. and other Technical Advisory Groups (TAGs) to WG15,
    the X3.159 Programming Language C Standard by the ANSI X3J11 committee,
    ISO/IEC JTC1 SC22 WG14 (the ISO and IEC version of X3.159),
    ANSI X3J16 on the C++ programming language,
    ANSI X3B11.1 on WORM File Systems,
    the National Institute of Standards and Technology (NIST),
    and their Federal Information Processing Standards (FIPS),
    X/Open and their X/Open Portability Guide (XPG),
    the Open Software Foundation (OSF),
    UNIX International (UI),
    the UniForum Technical Committee,
    the AFUU Working Groups,
    PortSoft,
    AT&T System V Interface Definition (SVID),
    System V Release 3, System V Release 4,
    4.2BSD, 4.3BSD, 4.4BSD,
    Tenth Edition UNIX, Plan 9 from Bell Labs,
    Mach, Chorus, Amoeba, GNU,
    and the USENIX Standards Watchdog Committee.

Subject: Moderator.

The newsgroup comp.std.unix and the mailing list [e-mail]
is moderated.  The moderator is Sean Eric Fagan.

Subject: Disclaimer.

Postings by any committee member in this newsgroup do not represent
any position (including any draft, proposed or actual, of a standard)
of the committee as a whole or of any subcommittee unless explicitly
stated otherwise in such remarks.  Postings and comments by the moderator
do not necessarily reflect any person's or organization's opinions.

* UNIX is a Registered Trademark of X/Open.
** IEEE is a Trademark of the Institute for Electrical and Electronics
    Engineers, Inc.
*** POSIX is not a trademark.
Various other names mentioned above may be trademarks.
I hope their owners will not object if I do not list them all here.


Subject: Postings.

Submissions for posting to the newsgroup and comments about the newsgroup
(including requests to subscribe or unsubscribe to the mailing list)
should go to two different addresses:

        DNS address            UUCP source route
Submissions    [e-mail]        uunet!std-unix
Comments    [e-mail]    uunet!std-unix-request

In addition to those addresses, I can be reached (electronically) as sef at
either uunet.uu.net, kithrup.com, or cygnus.com (e.g., [e-mail]).  If
you get a bounce from one of those addresses, or do not get a reply within a
week, send mail to one or more of the others.  For submissions, I prefer
[e-mail], as that is where I do the list maintenance.
Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail.  Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.

The mailing list is distributed on the Internet, UUCP, and elsewhere.
There is a redistribution list on BITNET for BITNET, EARN, and NetNorth.
Please send submissions from those networks to [e-mail]
nonetheless, because messages sent to the BITNET LISTSERV will not reach
the whole list.

If you have access to USENET, it is better (more efficient, cheaper,
less effort for me to manage) to subscribe to the newsgroup comp.std.unix
than to the mailing list.  Submissions should still go to the above
addresses, although many (perhaps most) USENET hosts will forward
attempts to post directly to the newsgroup to the moderator.

If you are on the mailing list, and articles are bounced back to me from
your address, you will be deleted from the list, and I will attempt to
get in touch with the administrator for your site, or what looks like your
site, and will reinstate your presence on the list when the problem is
fixed.

Posted articles may originate from uunet.uu.net, kithrup.com, or cygnus.com.
There are also occasional guest moderators, who may post from still other
machines.  Guest moderators are announced in advance by the regular moderator.

Subject: Archives.

Archives for comp.std.unix or [e-mail] may be found on UUNET.
Most of them are compressed, so if you don't have compress, get it first
(it's in the comp.sources.unix archives).

The comp.std.unix archives may be retrieved by anonymous FTP over the Internet.
Connect to ftp.uu.net with FTP and log in as user anonymous with password
guest.

The current volume is in the file
        ~ftp/usenet/comp.std.unix/archive
or
        ~ftp/usenet/comp.std.unix/volume.34
The previous volume, which is compressed, may be retrieved as
        ~ftp/usenet/comp.std.unix/volume.33.Z
and so forth for more ancient volumes.

For hosts with direct UUCP connections to UUNET, UUCP transfer from
host uunet should work with, for example,
        uucp uunet!'~ftp/usenet/comp.std.unix/archive' archive
You will have to put a backslash before the ! (i.e., \!)
if you're using the C shell or bash.

The output of "cd ~ftp/usenet/comp.std.unix; ls -l" is in
        ~ftp/usenet/comp.std.unix/list
and the output of "cd ~ftp/usenet/comp.std.unix; ls -l *" is in
        ~ftp/usenet/comp.std.unix/longlist

These files are updated rather sporadically; essentially, whenever
I come across this section at the beginning of each volume.

For further details, retrieve the file
        ~ftp/usenet/comp.std.unix/README


Subject: General submission acceptance policy.

Submissions are never ignored (although they might be overlooked).
If you don't see your article posted and you don't get a mailed
response from the moderator, your submission probably didn't arrive.
However, travel schedules and other business sometimes intervene
(and for that matter it can take many hours for a submission to
get to the moderator and the posted message to get back to the poster),
so you may sometimes not see anything for a few days.  If you wait
and still don't see anything, try sending again.

Although I try to read mail every day, and try to have articles posted
as soon as possible, there are sometimes circumstances which make that
difficult to impossible.  Too much work, flaky networks, and broken
hardware have all, at times, caused me to not be able to post an article
within minutes of it being posted.  Please do not keep resubmitting
your article, as it will only serve to annoy me.

As moderator, I reject relatively few articles:  maybe 1 out of 10;
although that amount varies, it is a good rough estimate.  I retain the
right to reject submissions.  If a submission does not appear relevant
to comp.std.unix, it is sent back to the submitter with a note saying
why it is not appropriate.  Usually this is because it just doesn't fit
the topic of the newsgroup, in which case I may suggest another newsgroup.
Sometimes it is because someone else has already given the same answer
to a question, in which case I ask if the submitter really wants it
posted.  Sometimes I reject an article because the information content
it is too low (e.g., twenty-five lines of included text, and a single-
line commanet).  Occasionally I suggest editing that would make an article
more appropriate to the newsgroup.  If a message appears to be directed
towards me, I will reply; if I am unsure, I wil ask the sender if
posting is really necessary or desired.

Very occasionally I may reject an article outright:  this will most likely
be because it contains ad hominem attacks, which are never permitted
in this technical newsgroup.  There are many other potential reasons
for rejection, however, such as inclusion of copyrighted material.
Fortunately, most such problems have not come up.

Note that while technical postings on technical subjects are encouraged,
postings about the politics of standardization are also appropriate,
since it is impossible to separate politics from standards.

Crosspostings are discouraged.  Submissions such as ``how do I find
xyz piece of software'' or ``is the x implementation better than the
y implementation'' that come in for multiple newsgroups usually get
sent back to the submittor with a suggestion to resubmit without
comp.std.unix in the Newsgroups: line.  Sometimes I'll crosspost if
there's clear relevance to comp.std.unix, but I always add a
Followup-To: line in an attempt to direct further discussion to a
single newsgroup, usually comp.std.unix.  This policy is useful because
crossposting often produces verbose traffic of little relevance to
comp.std.unix.  The most common response from me when I reject a submission
is to suggest that it belongs better elsewhere, usually some vendor-,
machine-, or operating system-specific newsgroup.  If you have a technical
question, before posting, it is usually sufficient to ask yourself if
the answer would be sufficient on a single vendor's machine, or if it is
necessary for it to be relevant to many different machines.



Subject: Editorial policy.

When posting a submission, I sometimes make changes to it.  These
are of four types:  headers and trailers; comments; and typographical.

Headers and trailers

Header changes include:
+ Cleaning up typos, particularly in Subject: lines.
+ Rationalizing From: lines to contain only one address syntax,
    either hosta!hostb!host!user or, preferably, user@domain.
    Very occasionally, this might cause an improper address
    to be generated.  If this occurs, and you think you may
    submit an article again, send me a note, and I will attempt
    to use an address you suggest next time.
+ Adding a Reply-To: line.  This usually points to the newsgroup
    submission address in the mailing list, but to the submitter
    in the newsgroup, for reasons too messy to detail here.
+ Adding the Approved: line.
+ Adding a References: line, if missing.
+ Deleting any Distribution: line, as detailed in the next paragraph.

The only distribution used in comp.std.unix is no distribution, i.e.,
worldwide.  If it's not of worldwide interest, it doesn't belong in
comp.std.unix.  Anything pertaining to the IEEE/CS TCOS standards
or committees (e.g., IEEE 1003, IEEE 1201), the ANSI X3.159 Programming
Language C Standard (X3J11), or the ISO 9945 POSIX work (ISO/IEC JTC1
SC22 WG15) is of worldwide interest.  If a submission arrives with a
Distribution:  line, such as na or us, I delete that line.

Every article has a trailing line of the form
>    Volume-Number: Volume 22, Number 42
This allows the reader to notice articles lost in transmission and
permits the moderator to more easily catalog articles in the archives.
Volumes usually change after about 100 articles, but are purely for
administrative convenience; discussions begun in one volume should
be continued into the next volume.  Due to the way news is transmitted,
articles may appear out of order at some sites if I send out several
at once.

Also, signatures that are excessively long may be truncated.  See
Gene Spafford's articles in news.announce.newusers for guidelines on
signatures.  Four lines will generally be considered sufficient,
and I tend to delete any excess white space or ``graphics.''

Very long quotations of previous articles are offtimes shortened, and
``standard'' inclusions indicators of '>' are replaced, if the author
has used some other form.



Subject: Comments

Comments by the moderator are sometimes added to clarify obscure
issues.  These are always enclosed in square brackets with the
closing mark ``-mod,'' [ like this -mod ].  Sometimes entire articles
appear that are written by the moderator:  these always end with
a signature that includes the words ``moderator, comp.std.unix.''

Comments by the editor of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and begin with the word ``Editor:''
[ Editor: like this ].

Comments by the publisher of the USENIX Standards Watchdog Reports
sometimes appear in those reports.  Such comments are always
enclosed in square brackets and end with the mark ``-pub,''
[ like this -pub ].

Entire articles may appear by the editor or publisher of the
Watchdog Reports, and those are always identified by the signature.

Subject: Typographical

People submitting articles sometimes enclose parenthetical comments
in brackets [] instead of parentheses ().  I usually change these
to parentheses to avoid confusion with the above conventions for
comments by the moderator, editor, or publisher.

Obvious misspellings, such as ``it's'' for the possessive or
``its'' as a contraction of ``it is'' are corrected (when I notice them).

Excess white space is deleted.  (This includes multiple blank lines at
times.)

I don't have any reallly strict policies on formatting, but, in general,
if an article has overly-long lines, or the author has right-justified
the margins, I will run it through fmt(1) before posting it.  See
Gene Spafford's articles in news.announce.newusers for guidelines on
formatting of news articles.

Redundant quoted headers are often omitted.



Subject: Common kinds of postings.

There are several sets of postings that reoccur in comp.std.unix
at more or less regular intervals.  Here are two of the most common.

USENIX Standards Watchdog Reports

The USENIX Association sponsors a set of reports after each quarterly
meeting of the IEEE 1003 and IEEE 1201 standards committees.  These
reports are written by volunteers who are already attending committee
meetings and are edited by the Watchdog Report Editor, who is Stephen
E. Walli <[e-mail]>.  Reports on other committees, such as X3J11,
are also included when available.  These reports are published in
comp.std.unix/[e-mail] and ;login:  The Newsletter of the
USENIX Association.  They are also available for publication elsewhere.

EUUG/USENIX ISO Monitor Project

The European UNIX systems Users Group (EUUG) and the USENIX Association
jointly sponsor an observer to the ISO/IEC JTC1 SC22 WG15 (ISO POSIX)
standards committee.  This observer, Dominic Dunlop <[e-mail]>,
writes a report after each WG15 meeting, of which there are usually
two a year.  These reports are published in the EUUG Newsletter
(EUUGN), :login;, and comp.std.unix.  They are also available for
publication elsewhere.

Archives of the EUUG/USENIX ISO Monitor Reports, the USENIX Standards
Watchdog Reports, and the Windsound/TIC Calendar of UNIX-Related Events
may be found on ftp.uu.net.  Retrieve ~ftp/usenet/comp.std.unix/README
for details.



Subject:  Comments

Please feel free to send me any comments you might have about my
job as moderator.  The group is meant to be informative and useful, and
you help determine that.  I may still make arbitrary decisions, but
I will probably do less such with some feedback.  In addition, if you
think I am doing a bad job, and not responding to criticisms, you
can post to the news.admin.misc newsgroup, although that may not do
much good.

Sean Eric Fagan, moderator, comp.std.unix and [e-mail].



Volume-Number: Volume 34, Number 1

From [e-mail]  Tue Feb 15 12:51:09 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdjr17129; Tue, 15 Feb 94 12:51:09 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdjr06821; Tue, 15 Feb 94 12:50:31 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11034; Tue, 15 Feb 94 09:51:08 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id JAA02322 for [e-mail]; Tue, 15 Feb 1994 09:50:06 -0800
Xref: majipoor.cygnus.com comp.std.unix:265
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.22: Computer Security Framework
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Feb 1994 09:44:40 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.22: Computer Security Framework


Randall Wayne Simons <[e-mail]> reports on
the January 10-14, 1994 meeting in Irvine, Ca.:

The POSIX.22 committee is defining a framework for
distributed computer security.  The framework will be a
common reference model to guide members of other POSIX
committees in addressing security needs in the standards
they are defining.

This was the first POSIX meeting I have attended, and my
main impression was of heads silently bowed over clacking
keyboards as multiple laptops were simultaneously applied to
modifying a document.  David Rogers, chair of the committee,
brought a troff version of the X/Open Snapshot called the
``Distributed Security Framework''.  POSIX.22 wants to keep
the X/Open and POSIX documents in sync since both groups are
working on the same problem.  The most recent version of the
document had just been reviewed by X/Open, and there were
numerous suggestions for improvement, including many that
required some restructuring of the document.  POSIX.22 took
on this task, and simultaneously reviewed and added their
own improvements.  Different sections of the document were
handed out to each committee member who then did the
cutting, pasting, and merging.

The reorganized document starts by introducing top level
information system security concepts, terms and models.
There is a description of threats, most of which got moved
to an appendix.  More detailed models define security
architectures and characteristics of interfaces to security
services.  Finally, the individual services and interfaces
are modeled and described in detail.  Interfaces support
both management and operational functions for each of the
services.

The basic services included are: authentication, access
control, security audit and cryptographic services.  At a
higher level, domain interaction services, which combine
various basic services in a distributed environment, include
user authentication and secure association service.

After more review and revision by both X/Open and POSIX.22,
the Framework document should be ready for balloting around
July.  The balloting group should form in April, so watch
out for it.  POSIX.22 had seven people at this meeting, and
there was plenty of work to go around.  Anyone willing and











- 2 -



able to help develop the POSIX Computer Security Framework
would be welcome at future meetings.  In general, there is
much to be done in security for POSIX - see the report from
POSIX.6.

























































Volume-Number: Volume 34, Number 2

From [e-mail]  Tue Feb 15 12:51:27 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdjr17146; Tue, 15 Feb 94 12:51:27 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdjr06885; Tue, 15 Feb 94 12:50:45 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11045; Tue, 15 Feb 94 09:51:17 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id JAA02334 for [e-mail]; Tue, 15 Feb 1994 09:50:16 -0800
Xref: majipoor.cygnus.com comp.std.unix:266
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.0: Guide to POSIX OSE
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Feb 1994 09:45:53 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.0: Guide to POSIX OSE


Kevin Lewis <[e-mail]> reports on the
January 10-14, 1994 meeting in Irvine, Ca.:

From The Battlefield

Work to get POSIX.0 approved continues.  The ballot
recirculation is in.  Let me first give you the statistics.
There are 86 total people in the balloting group of which 81
are eligible to vote.  A total of 75 ballots were returned.
The breakdown of those votes are as follows: 45 affirmative,
17 negative, 13 abstentions.  This represents a 92% return.
The 45 votes represent a 72% affirmative.  The ballots
consist of 167 comments and 182 objections which represent
about 25% of the total submitted during the first round of
balloting.

Before commencing resolution of the recirculation ballots,
in Irvine, we discussed a letter that had been received by
the IEEE from the ACM. This letter focused on the overall
IEEE balloting process, the concern that some of IEEE work
overlaps with standards work within X3, and that our guide
document still lacks the necessary level of consensus.  A
side point was that a portion of our rationale for rejecting
specific objections was poor.

This letter amounted to a hand grenade being lobbed in the
middle of our work, or, to quote a couple of the working
group members, a tactical nuclear attack.  I won't go into
too many details here, but the group did meet with two
people who were wearing ACM hats to share their concerns
along with those of ACM.  However, some working group
members who were also ACM members were quite disturbed by
the tone of the letter, part of which included an `_a_d
_h_o_m_i_n_e_m' (no, that isn't sexist - ed) attack against the
working group itself.  They were also distressed by the
approach taken by ACM of sending such a letter to the IEEE
without first having a dialogue with the group.  Words such
as `protest' and `malfeasance' made their way into the
discussion.

In my humble opinion, the only part of the letter I
considered valid (and I'm quite sure I would have the
unanimous assent of the group on this) was that portion
addressing our rationale.  And this, by the way, was quite
helpful.  In fact, it redirected our efforts for the better
during the week.  The group decided to return to the











- 2 -



unresolved objections from the first ballot for the purpose
of reviewing each one for possible acceptance or
correcting/strengthening our rationale for rejection, which
I admit was both weak in places and occasionally arrogant.

We completed this task, but did not get to the recirculation
ballots.  Because of this, and also due to the overall
feeling in the group that more productive resolution work
could be done at a meeting away from the quarterly PASC
(Portable Applications Standards Committee) meetings, we
agreed to schedule an additional meeting specifically for
the section leaders, to take place in March in the
Washington, D.C., area.  The only activity at this meeting
will be resolution of the recirculation ballots.  The exact
date has yet to be determined.

I feel quite strongly that we will be able to complete all
of the recirculation ballots at this March meeting.  What
remains now is the review-and-comment action by SC22, the
ISO subcommittee responsible for POSIX, which is now in
progress.  It looks like it will be October before we have a
document ready for submission to the IEEE Standards Board.

One more thing: the POSIX.0 working group is scheduled to
meet for two days at the April PASC meeting in Lake Tahoe.
This will be a skeleton crew to effect coordination with and
provide representation to some other key PASC committees,
such as the Profile Steering Committee and the Sponsor
Executive Committee.  In addition, this crew will monitor
the resolutions to the international committees that
directly or indirectly affect the guide effort.






























Volume-Number: Volume 34, Number 3

From [e-mail]  Tue Feb 15 12:53:12 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdjr17299; Tue, 15 Feb 94 12:53:12 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdjr07890; Tue, 15 Feb 94 12:53:04 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11251; Tue, 15 Feb 94 09:53:58 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id JAA02417 for [e-mail]; Tue, 15 Feb 1994 09:52:56 -0800
Xref: majipoor.cygnus.com comp.std.unix:269
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.6: Security Extensions
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Feb 1994 09:49:44 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.6: Security Extensions


Lynne Ambuel <[e-mail]> reports on the
January 10-14, 1994 meeting in Irvine, Ca.:

Introduction

As a first time snitch, I would like to indulge you with my
thoughts on standards - from a security geek's point of
view.  The general subjects include the peculiarities of
information security and those who live by it, various
activities taking place, and the status of the POSIX
security working group (previously known as P13.6).  Other
issues may creep into the discussion, but everything will
relate (no matter how obscurely) to these greater issues.

A Different Animal

Computer Security specialists are used to being called names
like `different,' `special,' and even `strange.' Although
some might take offense, I must agree with the
characterization.  Computer security really is a different
animal.  While most software designers and developers can
kick back once their code does what it is supposed to do, we
have just started - the important part is what the code also
does _n_o_t do.  For other applications, added functionality
brings cheers from users - more bells and whistles are
always better.  We add functionality and our users cringe -
more restrictions.  If we are real good, no one will notice
we have added more while our counterparts fly banners with
their latest new features.  Is it any wonder we can't get no
respect?

In the standards world, we are treated in a similar fashion.
We in the POSIX Security Working Group (P13.6) have the
unenviable job of policing the work of other POSIX groups to
be sure that gaping security holes are not mandated in the
standards.  That makes us lots of friends.  We add
interfaces that have sweeping effects on well-established
sets of interfaces.  We change those pillars of POSIX
interfaces and utilities to accommodate our added features.
And, our job never ends.  As new standards are developed we
continue to study them for the impact on the security of
POSIX-conformant systems.  We have just started looking at
what security means when systems are interconnected.  The
concepts of user identification and authentication and data
markings becomes remarkably complex once it is taken out of
a single system and spread throughout a network.  Let's say











- 2 -



that we have a lot of work to do in getting standards that
both meet the needs of the market and protect the
information of those using the end product, whether or not
they know they want it protected.

The Great Thing About Standards is There Are So Many To
Choose From

Not so many years ago computer standardization was a a
foreign and even ridiculous thought.  In the eighties,
however, we started moved toward a more friendly world and
everyone wanted to talk to everyone in the same language.
Organizations that previously held design and implementation
information excruciatingly close soon started sharing these
gems freely.  Security joined right in.  Standards were
written for what security should be in systems, first in
individual countries and then in international cooperation.
The utopian view is that someday (soon) there will be a
single security standard for the globe.  In addition,
several working groups were formed to look at
standardization of security interfaces, utilities, and data.
Some were folded into others.  Others sprouted and are still
separate.  These efforts continue with limited coordination
between the groups.  The problem with these parallel groups
is that, in these times of downsizing, organizations send
fewer representatives.  This means that each of the groups
have trouble making progress on their standards due to lack
of resources.  If these groups would pool their resources
substantive progress might be made, and there would be one
accepted standard instead of a handful of incomplete ones.

Progress of POSIX Security Working Group

Now that you have indulged my whinings about dwindling
resources I can tell you what we have accomplished.  A third
ballot of the five initial security options for POSIX.1
(access control lists, mandatory access control labels,
information labels, audit and fine-grained privileges) is
being distributed as you read.  However, it is about four
months behind schedule due to loss of half of the ballot-
resolution team.  In addition, we have identified several
interface areas that we need to tackle in order to complete
a set of security interfaces for portable applications
(identification and authentication, administration and
portable formats of security attributes, cryptography, and
network security interfaces).  Alas, we have been unable to
make any headway in these new areas because we cannot seem
to get enough organizations to submit proposals, nor can we
reach critical mass of people willing to do the work.













- 3 -



Sigh - What's a chair to do?  Flood the Internet with calls
for participation and proposals?  Done it.  Personal appeals
to ex-members?  Done it.  Complain and wallow in self-pity?
Done it.  Get mad and stomp around some Marriott?  Done it.
Ignore the problem and act like fifty new attendees will
show up?  Done it.  Continue the work and make progress, no
matter how slow?  Doing it - for as long as it takes.






















































Volume-Number: Volume 34, Number 6

From [e-mail]  Tue Feb 15 12:53:24 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdjr17320; Tue, 15 Feb 94 12:53:24 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdjr07865; Tue, 15 Feb 94 12:53:02 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11217; Tue, 15 Feb 94 09:53:45 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id JAA02393 for [e-mail]; Tue, 15 Feb 1994 09:52:43 -0800
Xref: majipoor.cygnus.com comp.std.unix:267
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX.5: ADA Bindings
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Feb 1994 09:47:14 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX.5: ADA Bindings


My Delbert L. Swanson <[e-mail]> reports
on the January 10-14, 1994 meeting in Irvine, Ca.:

The primary charter of the POSIX.5 group is to produce Ada
language bindings to POSIX standards.  The Ada binding for
POSIX.1, POSIX.5, has been published as an IEEE standard,
and we are now preparing bindings to the Real-Time
Extensions standards being developed by the POSIX.4 group.
These bindings have been designated as POSIX.20.

Draft 2 was developed as a ``thin'' binding to the Real-Time
Extensions.  That is, it merely made a correlation between
the constructs defined in the C version and the constructs
in the Ada version.  None of the explanations or semantics
are repeated.  This was done following on what was at that
time the policy of IEEE and the ISO community that all
language bindings would be thin bindings of a normative
language independent specification (LIS) of the standard.
Actually, our approach was even then a compromise, since
there was not yet a LIS version completed.

This draft was circulated for a first ballot last summer,
and the document was updated to account for comments and
objections. Meanwhile, the policy on thin bindings to LIS
versions of standards has changed, and so the group has been
revising the document in accord with our preferred approach
to begin with.

The next draft will be a thick binding.  That is, it will be
a complete specification of the interfaces for Ada
applications.  The advantage is that users will not need to
refer to multiple documents (Ada and C) to understand the
behavior of the Ada interfaces.  The disadvantage is in the
maintenance mode: if the baseline document changes, the
binding document needs to change correspondingly.

Another disadvantage is that it takes a lot more work to
produce a thick binding than a thin one.  An interim draft
was nearly completed for the January meeting, and we expect
to work on more issues between meetings, and then polish it
up to be ready for another full ballot after the April, 1994
meeting.

In January, the group re-examined our approach to Ada
bindings to the threads extensions.  We have concluded that
almost all of the functions offered in POSIX.4a are going to











- 2 -



be provided for Ada applications in the revision of the
language commonly called Ada9X, which is expected to be
granted standard status within the year.  It seems beside
the point for us to duplicate as OS functions these
capabilities, which will soon be available as language
constructs.  A couple of remaining pieces will be
incorporated into the new draft of POSIX.20.

One item of some concern to the group is the status of our
coordination ballot on POSIX.4a, the threads extensions.  In
the usual mode of cooperation between the groups, all but a
couple of our objections were resolved in discussion.
Unfortunately, the one that we consider most important has
been rejected on the grounds that it would reduce consensus.
It is our view that there are times, particularly when
handling signals, that it is important to be able to mask
asynchronous signals for the entire process.  This is
particularly important in Ada runtime environments, and it
is our view that it will also be important within C
programs.  The current C interface includes only per-thread
signal masks.  It is uncertain what the resolution of this
issue will be.

Meanwhile, we are preparing a revision to POSIX.5, to fix  a
few errors that have been found in the standard by
implementers (missing parameter, missing function
definition, error condition oversights).  The only way to
make ``substantive'' changes, even for errors, is to revise
the standard, which means balloting, etc.  This should be
ready for ballot as soon as the administrative details are
taken care of, which could be a few months.






























Volume-Number: Volume 34, Number 4

From [e-mail]  Tue Feb 15 12:56:29 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdjr17570; Tue, 15 Feb 94 12:56:29 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdjr08824; Tue, 15 Feb 94 12:55:42 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11555; Tue, 15 Feb 94 09:56:22 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id JAA02490 for [e-mail]; Tue, 15 Feb 1994 09:55:20 -0800
Xref: majipoor.cygnus.com comp.std.unix:270
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, POSIX Test Methods
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Feb 1994 09:51:44 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


POSIX Test Methods


Fred Zlotnick <[e-mail]> reports on the January
10-14, 1994 meeting in Irvine, Ca.:

The requirement that POSIX working groups develop test
methods in parallel with their standards was suspended at
the April 1993 meeting, and then finally withdrawn at the
following July meeting.  Nevertheless there are two active
test methods activities and more in the works.  The active
groups, which met at the October POSIX meeting in Bethesda
and at the January meeting in Irvine, are 23 (which is
revising POSIX.3, the standard that describes how to write
test methods) and 23.2 (which is developing test methods
for POSIX.2, Shell and Utilities). Well, technically it
wasn't the 23.2 working group that met, but it's the same
group of people.  More about that later.  Both of these
groups are chaired by Lowell Johnson of Unisys.

Revision to POSIX.3

The 23 working group has been working on a revision to
POSIX.3 for about a year and a half.  Although POSIX.3 has
been used successfully to write test methods for POSIX.1,
and its methodology has formed the basis for quite a few
commercial test suites, the use of this methodology has
exposed a number of problems.  The purpose of this revision
is to deal with these problems:

   o+ It is difficult to use POSIX.3 to write test methods
     for standards that modify other standards.  Real-time
     (POSIX.1b, which used to be POSIX.4) is a good example.
     Because the real-time standard consists of a collection
     of optional extensions to POSIX.1, every assertion for
     real-time must be conditional (type C or type D).  But
     there are other conditions within many real-time
     assertions, and this makes the statement of each
     assertion in POSIX.3 format rather cumbersome.
     Moreover, some of the options of POSIX.1b place
     additional semantic requirements on POSIX.1 interfaces
     such as _o_p_e_n().  Writing the assertions to test these
     requirements raises questions not adequately addressed
     in POSIX.3-1991:  How should they be numbered? How
     should they be conditioned?  How should they be
     classified (assertion-typed)?

   o+ A number of the users of POSIX.3 found the standard to
     be quite terse, and consequently difficult to











- 2 -



     understand.  A number of related but distinct concepts
     in POSIX.3 were often confused by users of the
     standard.

   o+ ISO had difficulty with the terminology of POSIX.3,
     which is not always consistent with that of some other
     test methods standards at the international level.

   o+ POSIX.3 was originally designed, and is specified, as
     only applying to POSIX standards.  The IEEE's Portable
     Applications Standards Committee (PASC) currently
     manages a number of projects, only some of which fall
     under the POSIX umbrella.  yet the test methods
     methodology of POSIX.3 applies to, and should be
     specified for, other PASC working groups such as P1327
     and P1328.  In general, the scope of POSIX.3 should be
     broadened.

The 23 working group began the week in Irvine with Draft
2.0 of the revised standard.  This draft had been completed
by the group's technical editor, Anthony Cincotta of NIST,
just prior to the meeting.  By the end of the week the group
had agreed on a set of changes that, when completed, will
produce Draft 3.  This draft should be suitable for mock
ballot.

The basic methodology of assertion based testing has not
changed in this revision, but the form in which assertions
are written has changed drastically.  The familiar,
frequently misunderstood and often vilified 2x2 matrix of
assertion types is gone.  The syntax of an assertion now
closely resembles a conditional sentence, with possibly many
nested conditions.  If an assertion applies only when
conformance to a particular version of a standard (e.g.
POSIX.1- 1993) is being tested, a condition indicates this
fact.  If an assertion depends on support of an option (e.g.
job control) a condition indicates this fact.  Sometimes an
assertion may specify required behavior but may only be
testable if the implementation supports optional features
(such as certain appropriate privileges). If so, a condition
indicates this fact.  Assertions are now labeled by
assertion IDs rather than assertion numbers; an assertion ID
is a string.

The new assertion structure promises to make assertion
writing easier and to allow the structure of test methods
standards to more closely parallel the base standards
against which they are written.

POSIX.2 Test Methods












- 3 -



The 23.2 working group has been working on ballot
resolution for the ballot of Draft 8 for the last four
meetings.  This means that, according to IEEE rules, it's
not really the 23.2 committee that's meeting.  Ballot
resolution is done not by the committee that wrote the
draft, but by a group of technical reviewers.  They just
happen (in this case, as in most) to be many of the same
people.

Ballot resolution for Draft 8 has been a slow job for a
number of reasons.  One is the size of the task: there are
almost 9 assertions in Draft 8.  Another is that despite
its size, Draft 8 was incomplete, and a number of ballot
objections made note of this fact.  Some of the missing
pieces (like assertions for _y_a_c_c) have not been easy to
supply.  Nevertheless, part of the task of resolving these
objections is to fill in those missing pieces.  Yet another
problem is that participation in this working group has not
been as regular as one might like, although the October and
January meetings were quite well attended.

Besides the incompleteness of Draft 8, major issues in
ballot included the fact that in many places the test
methods must be locale dependent but the draft frequently
addressed testing only in the POSIX locale.  Moreover, it
was often not explicit about this fact.  Other problems
included the omission of reasons for classifying assertions
as extended, and the omission of clear references for
reference assertions.

By the end of the October meeting the reviewers had made
enough progress to enable the technical editor, Andrew
Twigger of UniSoft, to produce interim Draft 8.5.  This will
not be balloted, but it was useful as a working document at
the January meeting.  At that meeting the technical
reviewers completed ballot resolution.  The technical editor
now has to integrate the resulting changes to produce Draft
9, which will go out to ballot.  The one thing of which we
can be certain is that Draft 9 will be much more complete,
and much larger, than Draft 8.

Test Methods for POSIX.1b

At the Irvine meeting the PASC Sponsor Executive Committee
(SEC) approved a new Project Authorization Request (PAR) for
test methods. The PAR creates a POSIX 23.1b project under
the direction of the 23 working group.  Its goal is to
write test methods for POSIX.1b.

You may recall that during the ``test methods wars'' the
POSIX.4 working group was grandfathered out of the











- 4 -



requirement (since lifted) to develop test methods along
with base standards.  Thus there are no test methods, even
in draft form, for POSIX.1b.  Yet there is substantial
interest in the development of conformance tests for POSIX
Real Time, and such tests need a specification.  In Irvine a
number of organizations, including representatives of
several DoD agencies (DISA, JITC), committed to provide
reop these test methods.  Ken Thomas of JITC
has offered to serve as vice-chair of 23 for the direction
of the 23.1b effort.  Bruce Weiner of Mindcraft has
offered to act as technical editor for the test methods
document.

















































Volume-Number: Volume 34, Number 7

From [e-mail]  Tue Feb 15 12:56:44 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdjr17619; Tue, 15 Feb 94 12:56:44 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdjr08964; Tue, 15 Feb 94 12:56:09 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11607; Tue, 15 Feb 94 09:56:44 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id JAA02510 for [e-mail]; Tue, 15 Feb 1994 09:55:43 -0800
Xref: majipoor.cygnus.com comp.std.unix:271
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: FOO
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Feb 1994 09:53:05 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Jason Zions) writes:

>Be prepared for a response along the lines of "reduces the
>concensus of the ballot group"; try to campaign ahead of time to get fellow
>balloters to support this particular objection of yours by reference. That
>is, post to this mailing list the exact objection and ask people to include
>in their ballots an objection that reads "I support objection so-and-so from
>Jason Behm at IBM regarding such-and-such."

I've gotten this response before, and it seems to me that the
reviewers (or whoever it is that reads objections and makes pithy
dismissals like "reduces the consensus") are acting prematurely here.

If I propose a new objection, then it is not known whether it will
reduce consensus or not.  To presume that all the other balloters
would disagree with an objection because they don't happen to quote it
is wrong.

Behind this seems to be reasoning that getting the standard finished
is more important than having the Best Possible Standard.  While it
might be impossible to get the Best, it is always worth another round
of balloting to substantive objections if there are no *technical*
reasons for rejecting them.

So, my plea to such reviewers is that before you conclude "would
reduce consensus", please try and think of *technical* reasons for the
rejection, and, when you fail to find any, then don't pretend you know
whether it would reduce consensus or not--becuase you almost certainly
can have no clue, particularly in the early stages of ballotting.


--
[phone] (H)    |   The soul of Jonathan was bound to the soul of David,
[phone] (W)   -+-   and Jonathan loved him as his own soul.
1105 Broadway          |  Then Jonathan made a covenant with David
Somerville, MA 02144   |    because he loved him as his own soul.


Volume-Number: Volume 34, Number 8

From [e-mail]  Tue Feb 15 22:21:31 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdld09309; Tue, 15 Feb 94 22:21:31 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdjr07866; Tue, 15 Feb 94 12:53:02 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA11234; Tue, 15 Feb 94 09:53:50 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id JAA02405 for [e-mail]; Tue, 15 Feb 1994 09:52:48 -0800
Xref: majipoor.cygnus.com comp.std.unix:268
From: [e-mail] (Nicholas M. Stoughton)
Newsgroups: comp.std.unix
Subject: Standards Update, What Next?
Organization: USENIX Standards Report Editor
Sender: [e-mail]
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 15 Feb 1994 09:48:18 -0800
To: [e-mail]

Submitted-by: [e-mail] (Nicholas M. Stoughton)

               USENIX Standards Report Editor

   Nicholas M. Stoughton <[e-mail]>, Report Editor


What Next?


So What Next?

Steady-State Behavior

Three years ago, attendance at POSIX meetings was around 340
people.  At Irvine this January, the number had fallen to
165, and it is expected (hoped?) that it will bottom out at
around 150.

So what's happened?  Where have all the contributors gone?
There's never a simple answer to questions like these, and
there are at least two major influencers at work in the
POSIX attendances.  The first is straight economics.  The
world is in a recession.  If your company is losing
millions, or even billions, of dollars each year, is sending
people to POSIX meetings the best way of spending what money
you do have?  Why not work at a distance, through the ballot
process?

Another key factor in the attendance figures is the type of
work that is happening now.  Three years ago, new standards
development was in full swing.  Now we are settling down to
a steady state.  Approved standards for POSIX.1, POSIX.2,
POSIX.3, POSIX.4 (aka POSIX.1b), POSIX.5 and POSIX.9 are all
there.  Maintenance work on these is now a major focus, and
that takes a different type of person on the working group.
At Irvine, a considerable amount of time was spent dealing
with interpretation requests, chiefly for the most blatantly
UNIX standards, POSIX.1 and POSIX.2.

Do we, the UNIX user community, care?  Let's give up going
to these meetings ... after all, someone else is sure to do
the right thing, aren't they?  It can't be all that hard to
maintain a standard!  Anyway, we don't want standards rammed
down our throats at every opportunity.

Unfortunately, the serpent whose name is invention is lying
there, coiled and ready to strike the moment that someone
stops saying ``But where's the existing practice''!  I've
lost track of how many times Jeff Haemer and I have trotted
that phrase out recently.  In the standards world, practice
really does make perfect.  If standards are to be rammed
down our throats, and that's a whole different discussion,
let them at least be palatable ones.













- 2 -



The rules of interpretation say that the approved standard
should be interpreted as loosely as possible.  If it was
actually wrong, it is up to a later revision to fix the
wording, but no one can complain in the interim.  This will
of course lead to lots of ``Weirdnix'' implementations:
systems that claim POSIX conformance, but are about as far
removed from UNIX as you can imagine!

So it is necessary to keep a a significant presence within
POSIX, attempting to restrain and guide the work occurring.
Existing documents need revision to clarify the wording to
help prevent the worst excesses of Weirdnix.  New POSIX
projects are still being introduced, but at a much reduced
level.  Many of these are not necessarily ``mainstream
UNIX'' things either - an ADA interface to time
synchronisation, Test Methods for POSIX.1b, the Realtime
standard (yes, the number _h_a_s changed, it used to be known
as POSIX.4), and so on.  Nevertheless, new direct UNIX
projects are not unthinkable, and we must be ready to meet
these challenges.

To give you a flavour of what is happening in the
interpretations process, Andrew Josey, the Vice Chair of
Interpretations has put together the following information:

Working   Mailing List                   Current Position            Outstanding
Group                                                                Requests
________________________________________________________________________________
P1003.1   [e-mail]   61 request pre-Irvine, 30      31
                                         addressed & in progress
P2003.1   [e-mail]   17 request, 5 complete         12
P1003.2   [e-mail]   30 requests pre-Irvine          0
P1003.5   [e-mail] 9 requests being processed 1
P1224     [e-mail]      6 requests have been answered  0
P1224.1   [e-mail]    2 requests have been completed 0
P1224.2   [e-mail]    3 requests being processed     0
P1327     [e-mail]      3 requests have been answered  0

In the past couple of months new draft guidelines for PASC
interpretations have been circulated and a BOF session met
at Irvine to discuss them further.

The guidelines attempt to address the issues of timely
response, and also of the scope of the interpretations.
They are now being followed and we hope to see some
improvement in the process over the next six months.

What Do You Care About Standards?

I would like to take this opportunity to solicit your
opinions as to what should appear in this column.  I was
recently invited to submit a series of articles to a










- 3 -



prominent Open System Magazine, but after I had sent in a
couple, I was told ``These are far too POSIX-centric.  What
about some other standards''?

There are certainly several other areas that might be useful
to report on, both in the _d_e _f_a_c_t_o and _d_e _j_u_r_e worlds.  But
rather than trying to read your minds, I'll solicit your
suggestions.  What else would you like to hear about?

Thank You

I would like to take this opportunity to publicly thank
Michael Hannah, a regular contributor to this column over
the years, for all his work with POSIX.9, his wit, and his
enthusiasm.  Michael has been promoted to a new position
within Sandia National Labs, running a 2000-node Intel
Paragon system - I know he has some stories that would
interest SAGE members - and will no longer be in a position
to continue his work with POSIX.  The first article I ever
edited for this column was from Michael, and the ease with
which I was able to work with him persuaded me to take on
the job permanently.  I am sure you will all join me in
wishing him every success in the future.






































Volume-Number: Volume 34, Number 5

From [e-mail]  Thu Feb 17 16:10:12 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdro26247; Thu, 17 Feb 94 16:10:12 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdro15518; Thu, 17 Feb 94 16:10:03 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05212; Thu, 17 Feb 94 13:11:21 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA11877 for [e-mail]; Thu, 17 Feb 1994 13:09:54 -0800
Xref: majipoor.cygnus.com comp.std.unix:273
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Feb 1994 13:02:02 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

[e-mail] writes:

>If I propose a new objection, then it is not known whether it will
>reduce consensus or not.  To presume that all the other balloters
>would disagree with an objection because they don't happen to quote it
>is wrong.

That is seldom the basis for rejecting-due-to-reduced-consensus. Generally,
contentious ballot objections cover old ground; that is, the objections that
make people jump up and down are usually ones that they've been jumping up
and down about in the working group for years. *Those* are the ones that get
rejected most rapidly for reducing consensus, because direct experience
within the group bears this out.

In other cases, it is a feeling by the ballot reviewers, yes. The reason
unresolved ballot objections *must* be published along with the response is
to flush out any too-quickly-rejected objections. If in fact the objection
does have ballot group consensus, this method delays the whole thing by one
ballot round; if the objection is in fact not supported by the ballot group,
then no delay is incurred and no extra work (due to incorporating the
objection) is wasted. The process is somewhat conservative of volunteer
bandwidth; after you've served as ballot reviewer or technical editor for a
standard, you'll understand why.

That's the reason I suggested you enlist support for your objection as early
as possible; if you get a strong degree of support (i.e. consensus goes your
way) then you don't incur the one-round delay in getting the change incor-
porated. Pay now, or pay later; take your choice. But history shows that
very rarely does ballot group consensus go in a direction different than
that predicted in a ballot response.

>So, my plea to such reviewers is that before you conclude "would
>reduce consensus", please try and think of *technical* reasons for the
>rejection, and, when you fail to find any, then don't pretend you know
>whether it would reduce consensus or not--becuase you almost certainly
>can have no clue, particularly in the early stages of ballotting.

Before you make broad generalizations about what a group of ballot reviewers
do or not have clues about, why don't you join a working group for the few
years it takes to get a document ready, then join the ballot review team.
*Then* tell me what those years of experience have provided in terms of
understanding the document and the people voting on it.

Jason Zions

Volume-Number: Volume 34, Number 10

From [e-mail]  Thu Feb 17 16:10:24 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdro26284; Thu, 17 Feb 94 16:10:24 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdro15655; Thu, 17 Feb 94 16:10:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA05224; Thu, 17 Feb 94 13:11:37 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA11889 for [e-mail]; Thu, 17 Feb 1994 13:10:11 -0800
Xref: majipoor.cygnus.com comp.std.unix:274
From: [e-mail] (Nick Stoughton)
Newsgroups: comp.std.unix
Subject: Re: Snitch reports
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>;
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Feb 1994 13:04:21 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Nick Stoughton)

>In the version of my snitch report that got posted to comp.std.unix, all
>consecutive zeroes were eliminated.  Thus the string "2003.1b" came out
>as "23.1b", and the "almost 9000" assertions in Draft 8 of 2003.2 were
>reported as "almost 9" assertions - not a very impressive number.

Woops! I have a broken set of mm macros for nroff (though the troff
versions work just fine), which mean that every page number is
reported as "- 000000000000000000000000000000000000000000000000000000n -"
so I pipe the output through sed on the way to Mail to
std-unix-request ... and I normally used "sed 's/0000*//'", but I
missed one of the zeroes this time!  Very sorry, will post a suitable
grovel to the net and actually truy and fix the macros rather than use
a quick hack approach like this again!


--
Nick Stoughton
Technical Manager, Open Technologies Group    Usenix Standards Editor
[e-mail]                [e-mail]
NB New Telephone Number: [phone]

[ Nick has obviously been drinking more of that green chartreuse
  stuff -- mod ]

Volume-Number: Volume 34, Number 11

From [e-mail]  Thu Feb 17 16:10:30 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdro26301; Thu, 17 Feb 94 16:10:30 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdro15705; Thu, 17 Feb 94 16:10:20 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA04929; Thu, 17 Feb 94 13:05:07 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA11627 for [e-mail]; Thu, 17 Feb 1994 13:03:42 -0800
Xref: majipoor.cygnus.com comp.std.unix:272
From: [e-mail] (Andy Feibus)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.6: Security Extensions
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Feb 1994 13:00:25 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Andy Feibus)

[e-mail] (Nicholas M. Stoughton) writes:
>Sigh - What's a chair to do?  Flood the Internet with calls
>for participation and proposals?  Done it.  Personal appeals
>to ex-members?  Done it.  Complain and wallow in self-pity?
>Done it.  Get mad and stomp around some Marriott?  Done it.
>Ignore the problem and act like fifty new attendees will
>show up?  Done it.  Continue the work and make progress, no
>matter how slow?  Doing it - for as long as it takes.

Not to sound like the voice of reason (me??  Nah.), but if
there isn't enough participation to get the job done, perhaps
there's not enough interest in having the standard.  In that
case, abandon the problem for now until enough folks get interested.
It'll happen if it's really important.  If not, then it's not
ready for standardization.

--
Andy Feibus.
Open Systems Today
[e-mail]

Volume-Number: Volume 34, Number 9

From [e-mail]  Thu Feb 17 17:18:35 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdrt02738; Thu, 17 Feb 94 17:18:35 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdrt16324; Thu, 17 Feb 94 17:17:26 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA07917; Thu, 17 Feb 94 14:18:40 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id OAA13912 for [e-mail]; Thu, 17 Feb 1994 14:17:14 -0800
Xref: majipoor.cygnus.com comp.std.unix:275
From: [e-mail] (Henry Spencer)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: U of Toronto Zoology
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 17 Feb 1994 14:09:23 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Henry Spencer)

In article <[e-mail]> [e-mail] (Michael I Bushnell) writes:
>If I propose a new objection, then it is not known whether it will
>reduce consensus or not.  To presume that all the other balloters
>would disagree with an objection because they don't happen to quote it
>is wrong.

It may be more than mere presumption.  How do you *know* that your "new"
objection is new?  Sometimes that trite-sounding phrase is an abbreviation
for "we spent six hours fighting over this at one of the meetings, so we
*know* there are violent disagreements on the matter".

>Behind this seems to be reasoning that getting the standard finished
>is more important than having the Best Possible Standard...

After a certain point, this is true.  It is important that a standard be
tolerable; it is important that it be timely; it is not necessary that it
be optimum.

--
Belief is no substitute                 | Henry Spencer @ U of Toronto Zoology
for arithmetic.                         |  [e-mail]  utzoo!henry

Volume-Number: Volume 34, Number 12

From [e-mail]  Fri Feb 18 16:44:09 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdvi29581; Fri, 18 Feb 94 16:44:09 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdvi24261; Fri, 18 Feb 94 16:43:52 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA22237; Fri, 18 Feb 94 13:45:16 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA14038 for [e-mail]; Fri, 18 Feb 1994 13:43:38 -0800
Xref: majipoor.cygnus.com comp.std.unix:276
From: [e-mail] (Sreenivasa Rao Tellakula)
Newsgroups: comp.std.unix
Subject: when is _POSIX_SOURCE required?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 18 Feb 1994 13:28:02 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Sreenivasa Rao Tellakula)

I have a doubt on _POSIX_SOURCE.

If I have two prototypes for the same function, one is posix version
and one is non-posix and if I have to put them in the header file, what
ifdef I have to use? Can I use _POSIX_SOURCE?

For example:

in example.h

#ifdef _POSIX_SOURCE
        extern int getgroups (int, gid_t *);
#else
        extern int getgroups (int *, int *);
#endif

is the above segment correct? If correct, this means all posix programs
needs to be compiled with cc -D_POSIX_SOURCE and is this an acceptable
constraint?

Whatever flags one has to specify with 'cc' to get a posix compliant
program is implementaion defined or is there any posix specification on
that?


--
[e-mail]
[phone](W)
[phone] - Fax

Volume-Number: Volume 34, Number 13

From [e-mail]  Fri Feb 18 16:44:13 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdvi29589; Fri, 18 Feb 94 16:44:13 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdvi24265; Fri, 18 Feb 94 16:43:53 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA22239; Fri, 18 Feb 94 13:45:18 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA14051 for [e-mail]; Fri, 18 Feb 1994 13:43:41 -0800
Xref: majipoor.cygnus.com comp.std.unix:277
From: [e-mail] (Michael I Bushnell)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Free Software Foundation, Cambridge, MA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 18 Feb 1994 13:29:45 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Michael I Bushnell)

In article <[e-mail]> [e-mail] (Jason Zions) writes:
>[e-mail] writes:
>>If I propose a new objection, then it is not known whether it will
>>reduce consensus or not.  To presume that all the other balloters
>>would disagree with an objection because they don't happen to quote it
>>is wrong.
>That is seldom the basis for rejecting-due-to-reduced-consensus. Generally,
>contentious ballot objections cover old ground; that is, the objections that
>make people jump up and down are usually ones that they've been jumping up
>and down about in the working group for years. *Those* are the ones that get
>rejected most rapidly for reducing consensus, because direct experience
>within the group bears this out.

This is the problem.  The fact that the working group might not have
liked the objection is *no clue* about the consensus that might or
might not be present among the balloting group.  The entire purpose of
the balloting group is to act as a check on the ideas and motivations
of the working group.  If objections are rejected because the working
group didn't like the idea, that only serves to defeat the purpose of
the balloting group.

If the balloting group is a reflection of the working group (so that
you can accurately predict the thoughts of the balloting group by
examining the working group), then the balloting group is useless.  In
fact, however, the balloting group has different motivations and
strategies than the working group.  The fact that the working group
has wrestled with something doesn't enable the technical reviewers to
make presumptions about the balloting group's consensus.

--
[phone] (H)    |   The soul of Jonathan was bound to the soul of David,
[phone] (W)   -+-   and Jonathan loved him as his own soul.
1105 Broadway          |  Then Jonathan made a covenant with David
Somerville, MA 02144   |    because he loved him as his own soul.


Volume-Number: Volume 34, Number 14

From [e-mail]  Sat Feb 19 16:45:41 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwdzb02159; Sat, 19 Feb 94 16:45:41 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwdzb05156; Sat, 19 Feb 94 16:45:40 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA17105; Sat, 19 Feb 94 13:47:21 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id NAA07002 for [e-mail]; Sat, 19 Feb 1994 13:45:32 -0800
Xref: majipoor.cygnus.com comp.std.unix:278
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: when is _POSIX_SOURCE required?
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
X-Submissions: [e-mail]
Date: 19 Feb 1994 13:27:59 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Sreenivasa Rao Tellakula) writes:
>needs to be compiled with cc -D_POSIX_SOURCE and is this an acceptable
>constraint?

It is certainly the case that, for the headers specified by the *C*
Standard, to enable any POSIX.1 extensions one has to somehow #define
_POSIX_SOURCE before inclusion of the standard header.  My opinion
is that you should not have both _POSIX_SOURCE and not-_POSIX_SOURCE
variations for the POSIX.1 interfaces, since there was no standard
before POSIX.1 anyway.  Go ahead and use the official whatever_t and
tie it into the mechanism you *must* have to make appropriate *_t
visible without polluting the application-reserved name space.  There
are a couple of approaches to this that will work; inspect existing
POSIX.1-compatible implementations of headers to get an idea of the
possibilities.

Volume-Number: Volume 34, Number 15

From [e-mail]  Sun Feb 20 10:37:35 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwebu02225; Sun, 20 Feb 94 10:37:35 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwebu18709; Sun, 20 Feb 94 10:37:33 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA23547; Sun, 20 Feb 94 07:39:28 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id HAA23917 for [e-mail]; Sun, 20 Feb 1994 07:37:31 -0800
Xref: majipoor.cygnus.com comp.std.unix:279
From: [e-mail] (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re:  when is _POSIX_SOURCE required?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
X-Submissions: [e-mail]
Date: 19 Feb 1994 13:30:31 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Chuck Karish)

[e-mail] (Sreenivasa Rao Tellakula) wrote:
>If I have two prototypes for the same function, one is posix version
>and one is non-posix and if I have to put them in the header file, what
>ifdef I have to use? Can I use _POSIX_SOURCE?

Yes, assuming that the first "int *" in the second prototype is
a typographical error that will be corrected.  This is a perfectly
appropriate use for _POSIX_SOURCE.

The #ifdef is not needed if gid_t is an int on your system.  The
definition could be expressed just as

     extern int getgroups (int, int *);

See POSIX.1-1990, page 33, lines 940-946.

>If correct, this means all posix programs
>needs to be compiled with cc -D_POSIX_SOURCE and is this an acceptable
>constraint?

This is not only acceptable, it is required.  When compiling a
POSIX.1 program, _POSIX_SOURCE has to be defined before any of
the POSIX.1 headers is #included.

>Whatever flags one has to specify with 'cc' to get a posix compliant
>program is implementaion defined or is there any posix specification on
>that?

This is outside the scope of POSIX.1.  If your system supports
POSIX.2, you can use the appropriate flags from that standard.
Of course, that means you won't be calling your compiler 'cc'.

    Chuck Karish        [e-mail]
    Mindcraft, Inc.     415 323 9000 x117


Volume-Number: Volume 34, Number 16

From [e-mail]  Sun Feb 20 10:37:38 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwebu02232; Sun, 20 Feb 94 10:37:38 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwebu18717; Sun, 20 Feb 94 10:37:36 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA23553; Sun, 20 Feb 94 07:39:30 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id HAA23929 for [e-mail]; Sun, 20 Feb 1994 07:37:34 -0800
Xref: majipoor.cygnus.com comp.std.unix:280
From: [e-mail] (Barry Margolin)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.6: Security Extensions
Organization: Thinking Machines Corporation, Cambridge MA, USA
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Submissions: [e-mail]
Date: 19 Feb 1994 13:33:48 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Barry Margolin)

In article <[e-mail]> [e-mail] (Andy Feibus) writes:
>Not to sound like the voice of reason (me??  Nah.), but if
>there isn't enough participation to get the job done, perhaps
>there's not enough interest in having the standard.

<sarcasm>
How surprising that they can't find interest among computer vendors to work
on security.
</sarcasm>

>Andy Feibus.
>Open Systems Today

And a journalist that would rather shrug this off.  Shouldn't you be
publishing this atrocious news?  (I could be presuming too much in saying
that you're a journalist -- as far as I know, you could be a janitor at OST
-- but it was just too hard to pass up.)

--
Barry Margolin
System Manager, Thinking Machines Corp.

[e-mail]          {uunet,harvard}!think!barmar


Volume-Number: Volume 34, Number 17

From [e-mail]  Mon Feb 21 21:42:16 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwehe22084; Mon, 21 Feb 94 21:42:16 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwehe01755; Mon, 21 Feb 94 21:42:15 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA20758; Mon, 21 Feb 94 18:44:26 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA24203 for [e-mail]; Mon, 21 Feb 1994 18:42:12 -0800
Xref: majipoor.cygnus.com comp.std.unix:281
From: [e-mail] (Doug Gwyn)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, POSIX.6: Security Extensions
Organization: U.S. Army Ballistic Research Lab, APG MD.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 21 Feb 1994 18:27:30 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Doug Gwyn)

In article <[e-mail]> [e-mail] (Barry Margolin) writes:
>How surprising that they can't find interest among computer vendors to work
>on security.

It's not clear that work is needed on security *extensions* when vendors
are still shipping OS products with such poor security quality control.
(How many sendmail "security patches" have there been so far?)
Like many other things in computing, people try to move on to new areas
without mastering existing areas first.  The result is that systems are
left in a real mess and seem to never get much better.

Volume-Number: Volume 34, Number 18

From [e-mail]  Tue Feb 22 21:22:46 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwekv15987; Tue, 22 Feb 94 21:22:46 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwekv03774; Tue, 22 Feb 94 21:22:45 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA19948; Tue, 22 Feb 94 18:22:41 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id SAA22312 for [e-mail]; Tue, 22 Feb 1994 18:22:41 -0800
Xref: majipoor.cygnus.com comp.std.unix:282
From: [e-mail] (Jason Zions)
Newsgroups: comp.std.unix
Subject: Re: Was this intentional in POSIX.1-1990?
Organization: Kithrup Enterprises, Ltd.
Sender: [e-mail]
Message-Id: <[e-mail]>
References: <[e-mail]>
Nntp-Posting-Host: rodan.uu.net
X-Submissions: [e-mail]
Date: 22 Feb 1994 18:15:37 -0800
Reply-To: [e-mail]
To: [e-mail]

Submitted-by: [e-mail] (Jason Zions)

>If objections are rejected because the working group didn't like the
>idea, that only serves to defeat the purpose of the balloting group.

Do you really believe that introducing a one-ballot-cycle delay before
incorporating a change which the working group thought shouldn't be
implemented and the ballot group does think should be implemented defeats
the purpose of the ballot group? Remember, that's the *maximum* impact that
can be caused by inappropriate rejection of a ballot objection that is later
supported by the ballot group.

>In fact, however, the balloting group has different motivations and
>strategies than the working group.  The fact that the working group
>has wrestled with something doesn't enable the technical reviewers to
>make presumptions about the balloting group's consensus.

The fact that they are technical reviewers gives them all the right in the
world to make presumptions about the ballot group's consensus; if they are
wrong, the ballot group will so inform them in the next round. As I have
stated before, technical reviewers need to adopt a position on each change;
there's nothing wrong with adopting a position which is conservative with
respect to the express intent of the working group in the absence of
conflicting direction from the bulk of the ballot group.

It sounds like the only procedure which is acceptable to you is for all your
objections to be accepted and acted upon by the TRs, and for the ballot
group to have to overturn you, if you're wrong, on the next round. Given the
track record of contentious ballot objections seldom being supported by
ballot groups, what justification do you give for TRs and Technical Editors
to expend significant amounts of time implementing changes that statistics
show will be backed-out in the next round?

Jason

Volume-Number: Volume 34, Number 19

From [e-mail]  Mon Mar  7 14:01:45 1994
Received: from relay1.UU.NET by rodan.UU.NET with SMTP
    (5.61/UUNET-mail-drop) id AAwgfs10051; Mon, 7 Mar 94 14:01:45 -0500
Received: from cygnus.com by relay1.UU.NET with SMTP
    (5.61/UUNET-internet-primary) id AAwgfs27296; Mon, 7 Mar 94 14:01:39 -0500
Received: from majipoor.cygnus.com by cygnus.com (4.1/SMI-4.1)
    id AA24582; Mon, 7 Mar 94 11:00:11 PST
Received: from localhost (news@localhost) by majipoor.cygnus.com (8.6.4/8.6.4) id LAA10768 for [e-mail]; Mon, 7 Mar 1994 11:00:10 -0800
Xref: majipoor.cygnus.com comp.std.unix:283
Newsgroups: comp.std.unix
From: [e-mail] (Sean Eric Fagan)
Subject: comp.std.unix will be DOWN
Message-Id: <[e-mail]>
Organization: Moderators -R- Us
Date: Mon, 7 Mar 1994 18:53:58 GMT
Apparently-To: [e-mail]

Due to some changes at uunet (most notably, it appears they've added
networking filters, the paranoid in me finds the recent rash of breakins
of various machines on the internet very suspicious), comp.std.unix
and the std-unix-list mailing list are DOWN until further notice.

I am unable to do list maintenance, which means that if you want to be
added or removed from the list, I cannot do much until things settle down
at uunet.  I can, however, continue to post articles, from other machines,
in the meantime.  To do this, however, any submitted article may have
to be mailed to [e-mail] (I can't even get in to change the
comp-std-unix alias; I did, however, just put up a .forward file, and
hopefully that will work for comp.std.unix submissions).  Since I will
be posting, entirely by hand, any articles that come in that way, there
may be errors (in particular, the lack of the Volume-Number bits at
the end).

I apologise for the delay and inconvenience, and wish I had had some warning
about this.  I'd also like to thank Shaun Oppenheimer for taking the time
to help me as much as possible.

Again, I apologise, and thank you for your patience.

Sean Eric Fagan
Moderator, comp.std.unix