Re: [STDS-802-16] comment submission format for P802.16-REVd recirc
David,
The delta document contains all of the changes done to D3,
e.g. there is no change which is not reflected.
The existing problems are of two types: 1. table and figure
references numbers (although these can be ignored, assuming
that the auto references are fine) and 2. changes done to
figures and tables.
For type 2, you can view the changes by looking at second
figure table/figure compared to the first one.
The only (possible) problem that I can see is wrong
table/figure reference which was given in
comment/contribution to implement (I had several "see table
NNN" type of changes which referenced to D3 tables but
commenters did not find enough time to do the search by
themself, so I had to guess/make common sense), those
probably should be verified, but again the delta document can
be used for this as well.
Regards,
Itzik.
---- הודעה מקורית ----
>תאריך: Fri, 2 Apr 2004 14:19:56 +0100
>מאת: David Castelow <DCastelow@AIRSPAN.COM>
> ושא: Re: [STDS-802-16] comment submission format for
P802.16-REVd recirc
>אל: STDS-802-16@listserv.ieee.org
>
>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.
>> >
>>