[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: stds-802-16:SYSREQ
[Notice: It is the policy of 802.16 to treat messages posted here as non-confidential.]
David,
Thank you very much for your message. I think we're on the same page for
managing the editing process going forward. And I too must appologize for my
rather harsh reaction to your message--I realize your interest is also to move
things forward efficiently. I look forward to your help managing the
comment/resolution/editing process and meeting #2.
Best Regards,
Brian Petry
"Jarrett, David (David)" <djarrett@lucent.com> on 07/19/99 10:17:38 AM
Sent by: "Jarrett, David (David)" <djarrett@lucent.com>
To: Brian Petry/PA/3Com
cc: "'stds-802-16 @ieee.org'" <stds-802-16@ieee.org>
Subject: RE: stds-802-16:SYSREQ
I think I need to publicly apologize to Brian, and try to clear the air so
that we can be effective moving forward.
First, I truly didn't mean for my comments to reflect personally on Brian or
how he handled the meeting in Montreal. I thought he handled the meeting
well, considering he was filing 2-3 different roles (Chairs, Editor,
Parliamentarian), and that there were many new people who had to be brought
up to speed on what 802.16 is about, and how we are going to do things.
Brian clearly did a great deal of work in pulling together a draft of the
Systems Requirements document, given a) few contributions, b) many late
contributions (including mine), and c) a lack of on-line discussion before
the meeting. I for one didn't expect to have any substantial on-line
discussion. I'm used to standards activities were there is some on-line
discussion, but where the real work is done at the meeting. Perhaps
everyone else was just trying to get their contribution done, as was my
case. However, the upshot of my comments is that the editors job should by
definition be easier than it has been for Brian up to now. If there are
specific, agreed upon text changes, then the editor doesn't have to provide
it before the meeting. Of course there will still be a lot of work in
making a readable document, and every purely editorial change shouldn't need
to be voted by the full membership.
To address Brian's flames:
1) The idea of representing the individual and not the company is different
than other standards groups I've attended; I need to get used to the IEEE
way.
2) I didn't know I was the Vice Chair! I had to leave before the last half
of the closing plenary, and I've been out of the office, and am just now
reading all the e-mails.
Again, I want to apologize to Brian, and to the group if it appears I was
unfair with my comments. See you in Denver.
DWJ
--
-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-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
> -----Original Message-----
> From: Brian_Petry@3com.com [mailto:Brian_Petry@3com.com]
> Sent: Thursday, July 15, 1999 9:09 AM
> To: Jarrett, David (David)
> Cc: 'stds-802-16@ieee.org'
> Subject: Re: stds-802-16:SYSREQ
>
>
>
>
> 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
>
>
>
>
>
>
>