stds-802-16: SYSREQ: System Requirements Document Editing Process

[Brian_Petry@3com.com]

[Notice: It is the policy of 802.16 to treat messages posted here as non-confidential.]




Hello,

I am sending this message to those people interested in contributing to the
creation of a System Requirements/Functional Requirements document for IEEE
802.16 Broadband Wireless Access (BWA) systems.

My name is Brian Petry, and I have been appointed editor for a
system/functional requirements document.  We would like to proceed quickly to
produce a draft by the next IEEE 802.16 meeting, July 5, 1999.

Roger Marks, our 802.16 chairman, has set up an email list reflector for
802.16 that we will use for discussing system requirements issues and sending
out document revisions.

To submit document content contributions or feedback and discussion, you can
send mail directly to the list.  The address is "stds-802-16@ieee.org".
Please format your email subject line like this:

SYSREQ: [blah blah blah]

This way, people on the 802.16 list can manage their email effectively, by
skipping over the SYREQ messages if they do not want to participate, deleting
the message, filing it away, setting up an automated filter, etc.  The mail
exploder also automatically prepends an extra "stds-802-16: " to the subject
line, making it easy to distinguish 802.16 messages.

Hopefully, utilizing this email list, we can achieve consensus on many issues
before the next face-to-face meeting.  As editor for this particular document,
my job is to gather input from you (through the email reflector), monitor
on-line discussion and edit the document.  Periodically. I will email updates
of the in-progress document to gather more comments.  I will integrate content
into the system requirements document once I feel particpants have reached a
consensus on the content.  In this capacity, I hope to detect consensus among
participants on various issues, and flag other issues as items of contention.
However, if consensus is not obvious, we can discuss the issues, and vote on
them, at the July meeting.

Issues or text in the document that meets with contention among contributors
must eventually be "worked-out" through debate and compromise.  Foreseeing
some debate, I ask in advance for your help in resolving these issues by
requesting that if you strongly agree or disagree on an issue, to please state
reasons for your points of view and post your views to the email list.  In
case we have issues that cannot be clearly resolved via email, perhaps we can
clear them up at the next face-to-face meeting, where you can submit your
views in person.

One important issue with our email-based discussion is that the 802.16
reflector is open to everyone.  We would like to solicit open input from the
global industry, especially license holders and operators, to ensure broad
participation.  The 802.16 working group welcomes and depends on industry
input on the system and functional requirements to ensure that 802.16
standards, notably the "air interface," ultimately meet industry requirements
and expectations.

However, some participants may have copyrighted or confidential information
that they would like to submit but feel they could not responsibly send it due
to the open email reflector.  In this case, we encourage participants to
extract the non-sensitive information and submit it.  But if it is not
possible, practical, or convenient to do so, you may send the contribution to
me (brian_petry@3com.com) and, working with Roger (marks@nist.gov), I will
assign it a number and distribute it privately.  In the future, we may get a
password-protected web page that will offer more control over distribution.
Even then, you should expect that such content will be discussed openly on the
email reflector.  We hope that system requirements, which are so fundamental
to understanding the properties of a standard air interface, should contain no
proprietary information.

Another issue is that today we do not have email threading or automatic
archiving enabled on the 802.16 reflector.  But I will be sure to archive
everyone's messages concerning the system requirements document and make the
archive available somehow.  And even when threading is enabled, we will
archive each substantive contribution by assigning it a number and posting it
on the 802.16 web page.  If you have a substantial contribution and you want
to assign it a number and put the number (for instance, in a page header or
title page) in your document, feel free to send me email and I will allocate a
document number for you.

This paragraph contains some minutiae for our document numbering plans.  If
you need a cure for insomnia, read on.  For any contributions that contain an
attached document, or substantative text, I will act as a "librarian" by
archiving the document and assigning it a number in accordance with the IEEE
LMSC numbering conventions.  The format for a document number produced by a
task group that does not fall under an active PAR is "802.16{tg}-yy/m" where
{tg} is a task group designator (system requirements) and yy is the year
designator and m is a sequence number which starts at 1 at the beginning of
each year and is increased by 1 each time a document number is assigned.  The
{tg} field isn't very flexible.  The allowed formats are: one letter, two
letters, or one letter followed by one number.  Here's my idea (we're open to
better ideas) for the {tg} field for system requirements documents: The first
letter is 's' which stands for "System Requirements."  That distinguishes our
documents from other task groups (MAC, coexistence, IF I/F, etc.)  For the
next character, we use a digit (0-9) to identify documents that the system
requirements group _produces_ as a committe.  To identify documents that are
contributions from members, we use the letter 'c' (stands for "contribution").
For example, we reserve the number "802.16s0-99/1" for the first revision of
the system requirements document.  And the first contribution gets the number
"802.16sc-99/1".