Re: [STDS-802-16] comment submission format for P802.16-REVd recirc
Itzik,
And that is my point: that the problems all arise from the delta.
Given the short time for the recirc (and maybe for procedural reasons as well), I didn't think I could suggest reissue of the delta, but the delta contains a number of errors and we now have to infer what the changes are.
I realise that the formal recirc has been issued as based on the D4delta.
The implication is that ALL such errors need to be flagged as problems.
Alternatively we have to use D4 and D3 to check that the differences have been applied correctly and then re-write the resulting comments as changes to D4delta resulting in extra work PLUS the headache of uncertainty as to what D4delta actually contains (e.g. that it contains as explicit text the <<Figure 1>> line for example).
That is why I was asking if we could use D4 instead of D4delta, though maybe procedural reasons may preclude it.
Regards
David
-----Original Message-----
From: owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org]On Behalf Of Itzik Kitroser
Sent: 02 April 2004 12:15
To: STDS-802-16@listserv.ieee.org
Subject: 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.
> >
>