Re: stds-802-16:SYSREQ

[Brian_Petry@3com.com]

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



My responses to Mr. Jarrett's comments follows.

1. Yes, I as editor, took some liberty in filling in the gaps in the first draft
of the document.  The contributions we received did not flow together enough to
form an "even" narrative.  Generally, the task group accepted this mode of
operation.  Further, at the Austin 802.BWA study group meeting, I was tasked
with doing just that: to get a draft out in an accelerated manner, based on
consensus I could detect from the contributions and on-line debate.  I also
clearly stated how the editor arrived at the first draft in the various
"disclaimers" in the top sections of the document.  One thing that did not
happen was on-line debate on various issues (e.g., issues in the contributions)
that would have allowed me to clearly "detect" consensus.  This lack of
participation made my job a little more difficult, but I still got it done.
Thus, I object to Mr. Jarrett's negative comments on the editing process up to
meeting #1.

2. The group voted (unanimously) to accept the draft (after some edits at
meeting #1) as the working baseline.  Basically that means we are not starting
over again.  I think that clearly justified the editiing process up to that
point.

3. We wasted some time at meeting #1 discussing "process."  This lasted little
over 1 hour.  I would not say that was "much" of the time.  But it was my
fault--the process I had in mind clearly was not going to work and I could not
think of a new process quickly enough, so I opened the floor to suggestions.
After the 10:00AM break, with some helpful suggestions from Gene Robinson and
Roger Marks, I had resolved our process issues for the meeting, and the rest of
the day went very smoothly, including the time we allowed for debating some of
the suggested modifications to the document.  I appologize for wasting about an
hour of people's time at the meeting.

4. The process going forward will be to accept specific insertions, deletions
and changes to the document.  The editor will not make unilateral changes to the
document unless they are non-content changes, such as formatting, etc.  The
system requirements task group leadership will send mail to the reflector
discribing this process shortly.

5. At meeting #1, the group identified some areas that require more
contributions.  We will be sending a call for contributions shortly.  At meeting
#2 (Denver), the group will decide how to proceed with the contributions.

6. Some issues that are controversial and/or not covered adequately by
contributions may be allocated (refered) to sub groups to work out a
consensus/compromise proposal.

[Flame On]

7.  Lucent, as a company, has no input into our process.  Only the individuals
who participate have input.

8. Mr. Jarrett is the vice-chairman of the system requirements task group.  As
such, he should discuss his opinions with the rest of the task group leadership
before blasting suggestions to the list and forcing us (me) to waste our
valuable time writing (and reading) followup messages such as this one.  I hope
in the future he can work more constructively with the group.

[Flame Off]

Best Regards,

Brian Petry






"Jarrett, David (David)" <djarrett@lucent.com> on 07/15/99 08:11:52 AM

Sent by:  "Jarrett, David (David)" <djarrett@lucent.com>


To:   "'stds-802-16 @ieee.org'" <stds-802-16@ieee.org>
cc:    (Brian Petry/PA/3Com)
Subject:  stds-802-16:SYSREQ





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

Brian:

Here are some ideas on procedures to help us move forward.

In the interest of speed, the Systems Requirements editor took the liberty
of adding text to the System Requirements draft before the July meeting.
These additions were either from 1) contributions that had not been
discussed, or 2) discussion at previous meetings that was not reflected in a
contribution.  This was an honest attempt to use common practice within the
Internet standards community to speed the work up and provide early inputs
to the MAC and Phy task groups.  However, it seems that this approach may
have been counter productive, as much of the time at the July meeting was
spent commenting on the process, and we only reached consensus on a fraction
of the issues!

Going forward, Lucent proposes the content of the System Requirements
document (and 802.16 documents in general) should strictly be based on
contributions that have been discussed in the meeting, and result in agreed
changes to the document.  We should never edit the document before proposed
changes have been agreed upon.  This may actually speed us up, since the
focus will be on agreeing on specific changes first.  Thus, we propose the
following procedure:

1) Contributions are made on reflector; should have proposals for specific
edits (to text and figures), new work items, etc., at the end
2) Allocated to correct group(s) (some should be presented to multiple
groups)
3) Discuss in group, if don't achieve "quick" (15 minutes?) consensus on
proposal, refer to subgroup of interested parties to attempt resolution;
bring subgroup proposal back to main group
4) Determine accepted proposals at final working group session
5) Edit document and Issue updated version after all proposals have been
accepted

We may also want to consider chartering sub-working groups for large items
(management, QoS parameters, etc.).

--
-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-0-
David W. Jarrett         Lucent Technologies
Voice: 1-408-952-7452    Wireless Broadband Networks Division
Pager: 1-888-876-0854    890 Tasman Drive
Fax: 1-408-952-7456 M/S 08-09
E-mail: djarrett@lucent.com   Milpitas, CA 95035-7912