Re: [STDS-802-16] comment submission format for P802.16-REVd recirc
I appreciate Itzik's clarification of the status of the delta
document. While it includes the required information, I take David's
point that the comment and resolution process will be less
complicated if we focus our editing efforts on the clean version.
Therefore, I'd now like to request that, if you are preparing Sponsor
Ballot 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 clean draft
P802.16-REVd/D4.
(c) Use _Commentary_ correctly. This means:
(1) If you re-use an old Commentary database, don't send the old comments.
For example, use "Delete all Records" before you start.
(2) In the upper-left corner of the window, choose the layout
"Create and Submit Ballot"
(3) Fill out the information
(4) For "Document under Review," write "P802.16-REVd/D4(clean)".
(5) When you are done, click "Save Data to File".
(6) Submit the file following the Sponsor Ballot instructions provided by the
IEEE-SA Balloting Center, choosing the "File Upload" option.
Thanks,
Roger
At 19:45 +0200 04/04/02, Itzik Kitroser wrote:
>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.
>>> >
>>>