Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] comment submission format for P802.16-REVd recirc



David,

The problems that you have pointed out comes from the Delta creation
process:
- The automatic delta process does not mark changes inside figures/tables,
but presents each changed table/figure as two tables/figures (the new after
the old), and advance the auto numbering for both (that should explain the
numbering and referencing issues)
- Regarding figure 1, it exists as hidden in D4, I didn't manage to get rid
of it when I issued D4.

The main problem of working with the clean version, is that the sponsor
ballot members are using the delta document as baseline.

Itzik.

> -----Original Message-----
> From: owner-stds-802-16@listserv.ieee.org
> [mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of David Castelow
> Sent: Friday, April 02, 2004 11:21
> To: STDS-802-16@listserv.ieee.org
> Subject: Re: [STDS-802-16] comment submission format for
> P802.16-REVd recirc
>
>
> Roger,
>
> Given that there are errors in the delta version that do not
> exist in the vanilla D4 document, is it wise to use the delta
> document as the basis for resolution of comments?
> The case in point is Page 401 of D4, page 404 of D3 and page 450
> of D4delta, where there are a number of errors in D4delta that
> appear to be a result of the delta process, not the standard as
> written in D4.
>
> The faults I have seen in this vacinity are: (refering to D4delta
> page numbers)
> Page 450, Line 3: Reference to incorrect table number (says 193,
> should be 192 according to D4).
> Page 450, Lines 9-63: No redline marking to show changes.
> Page 450, Line 7: Table number is shown as 207 (should be 186
> according to D3).
> Page 451, Line 4: Table number shown as 208, should be 192
> according to D4.
> Page 451, Line 64: Spurious "Figure 1-OFDM randomizer downlink
> initialization vector for burst# 2...N" included.
>                                 This is not present in either D3 or D4.
>
> These ought all to generate comments that will slow down the
> comment resolution process, and there may be many others: once I
> had seen these I stopped using the delta document.
>
> Rather than do this, or have the editor generate a new D4delta,
> please can you consider using the vanilla D4 document as the
> basis of comment resolution.
>
> Regards
>
> David Castelow
>
> -----Original Message-----
> From: Roger B. Marks [mailto:r.b.marks@ieee.org]
> Sent: 01 April 2004 18:48
> Subject: comment submission format for P802.16-REVd recirc
>
>
> Dear IEEE 802.16 Working Group Members,
>
> If you prepare comments in the P802.16-REVd/D4 recirc, please observe
> the following:
>
> (a) use _Commentary_ format
> (b) when referencing Page/Line numbers, refer to the document under
> recirc: P802.16-REVd/D4delta. In other words, reference the marked-up
> version, not the clean version of the draft. Otherwise, the BRC will
> be confused.
>
> Thanks,
>
> Roger
>
> P.S. The recirc opened today, as promised.
>
>
> >Dear IEEE 802.16 Working Group Members,
> >
> >At Session #30, the IEEE 802.16 Chair and Vice Chair were tasked to
> >complete the details of a framework process for resolving comments,
> >without a face-to-face meeting, in the Sponsor Ballot Recirculation
> >of IEEE P802.16-REVd/D4.
> >
> >Ken and I have developed a complete procedure based on electronic
> >dialog centered on our "Commentary" database software. We think this
> >can work very well. The full documentation, including a detailed
> >schedule, is in:
> >
> >"Comment Resolution Procedure for Sponsor Ballot Recirculation of
> >IEEE P802.16-REVd"
> >IEEE 802.16-04/18 <http://ieee802.org/16/docs/04/80216-04_18.pdf>.
> >
> >According to the procedure, the comments will be resolved by a
> >Ballot Resolution Committee (BRC) composed of the all the current
> >members of the IEEE 802.16 WG. This procedure will require time and
> >attention of the members, with, in some cases, relatively short
> >turnaround times. I suggest that you study the procedure carefully
> >and try to keep free time on your calendars, particularly in the
> >period 16 April - 8 May (and beforehand for those submitting
> >comments). Depending on the level of comment during recirc, this
> >procedure may place significant demands on the time and attention of
> >the WG members.
> >
> >Regards,
> >
> >Roger
> >
> >P.S. I have been promised that the IEEE-SA Balloting Center will
> >open the recirc by tomorrow. The procedure assumes they will.
> >
>