Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Itzik, There are two main reasons to introduce the text changes in C802.16maint-05/102r5
(Comment#107). Firstly, in the first PUSC DL zone the DL_PermBase
is set to “0” for renumbering in item (2), and at the same time, DL_PermBase is set to “IDcell”
for permutation equation in item (4). What is the value of DL_PermBase
in the first PUSC zone? Secondly, there is no such parameter as DL_PermBase in the first place until a zone switch by STC_DL_Zone_IE().
DL_PermBase is a parameter of STC_DL_Zone_IE(). Before that, what is DL_PermBase in the first DL zone? With the text changes of C802.16maint-05/102r5,
the DL_PermBase conditions are rightfully removed
from the first PUSC zone, no more ambiguity in interpretation. What is more important, the procedure of IEEE WG should be
strictly enforced. IEEE C802.16maint-05/102r5 was well debated in both
16e/16maint joint session and 16maint session alone. You should have been aware
of the debates and the revision changes because of that. The comment# 107 was
finally voted and accepted as modified. Editor is a tough job. I do respect
your opinion, and you had your chances to voice it at the debates. But you
should not have the right as an editor to choose not to incorporate the whole text
changes as part of the solution in C802.16maint-05/102r5. You should have at
least consulted the originators of the contribution for clarification if you
need. I believe the text changes suggested in C802.16maint-05/102r5 should have
been incorporated into Cor1/D3. Regards, ZTE San Diego, Inc. -----Original Message----- Hi, In the first PUSC zone and PUSC zone with ‘Use
all SC indicator=0’, DL_PermBase shall be set to ‘0’ for Renumbering Sequence and also
DL_PermBase shall be set to “preamble IDcell” or “DL_PermBase
from STC Zone IE” for Inner Permutation (eq. 111) in the first PUSC zone
and PUSC zone with ‘Use all SC indicator=0’, respectively. This is
the current form of standard. For one
parameter, we have to have two different values at the same time in certain zones. Comment#107 was discussed long enough and the corresponding contribution
IEEE C802.16maint-05/102r5 had been revised 5 times and successfully cleared
all the ambiguity mentioned above. I believe comment#107 should be incorporated into the draft without
further. Thanks, Jungnam -----Original Message----- Hi, When
implementing the comment, I found out that the resolution was already
incorporated in the draft but in a different way, which I found to be cleaner. Sometimes
during the process, we accept several comment that change the same paragraph
and therefore creates ambiguities (and even in some cases in the past
contradict each other). I think that my job as a technical editor is to try to
solve such problems in a way that the meaning of the comment is retained. If you
read the current text, you will find out that the indention of the comment is
clear from the text. For this
specific case, here is what was proposed, and what is currently in the text: In item
(2), the intention of the comment was to differentiate between the first
DL_Zone and the rest, and to do this by changing the formula. In the final text
in the current draft says: "In the first PUSC zone of the downlink (first
downlink zone) the default used DL_PermBase is 0. When the 'Use all SC
indicator=0' in the STC_DL_Zone_IE(), DL_PermBase is replaced with 0. For All
other cases DL_PermBase parameter in the STC_DL_Zone_IE() shall be
used.." This exactly expresses the comment but
without changing the formula to two different cases but defining how to set the
DL_PermBase for the first DL zone (by setting it to zero is we get the first
part of the formula and for the rest we get the other part). I think that this
is much cleaner, express the intention of the comment and thus reaching the
goal. The same this applies also to equation
(111) without the need to change the formula. I agree that my work is to implement the
comments, but in this case, I found myself changing things to express exactly
what we already changed in the corrigendum and thought that this is not
logical, from pure editorial reasons. I don't make any technical decisions, but
still see my work to have a clean document (again from editorial perspective)
and not rewriting same section again and again leaving the same output. With respect, Itzik. From:
owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]
On Behalf Of Jungnam Yun When
I opened Cor1_D3, I found one of
accepted
comments that has not been applied in the
Draft. Since this kind of thing happened many times
before, I simply thought that the original
commenter
might
need to make another comment to appeal this
editor's mistake. But then, I opened the commentary files, 80216-05_21r2 and
80216-05_21r3 - 21r2 was released during the
closing plenary session and 21r3 was released yesterday along with the Draft
Cor1_D3. For comment # 107, accepted
text changes have not been applied and there is an explanation in
80216-05_21r3. In 80216-05_21r2,
IEEE
C802.16maint-05/102r5 Vote to call the
questoin: In favor:
7 Against:
0 Vote to accept the
comment as modified In favor:
5 Against:
0 Passes And In 80216-05_21r3, Editor's Note Did not make any
changes in items (2)
and (4) in section
8.4.6.1.2.1.1 since previous changes,
acheived the same target in a cleaner way. Also, for the
change in equation (111), the text in
the description of DL_PermBase explicitly says that the parameter is set to IDCell
in the first DL_Zone, so there is no need to extend the formula to state this
again. I was surprised by
"editor's Note" in 80216-05_21r3. I believe that the editor
doesn't have the right to overturn group's decision. Once any
type of group decision is made during the session, accepted changes should be
incorporated in the draft and any concern on the change should be
presented
by comments in next session. If the editor could overturn groups decision as
above, all the discussion during the
session can be meaningless. The chair or editor of
maintenance task group may need to explain
above
note. Thanks, Jungnam Yun -----Original Message----- The new draft IEEE
P802.16-2004/Cor1/D3 is now available:
<http://ieee802.org/16/private/drafts/maint/P80216_Cor1_D3.zip> A markup version is also
available:
<ttp://ieee802.org/16/private/drafts/maint/P80216_Cor1_D3delta.zip> Both require the 802.16 user
name and password. For more information on password-protected
access, see: http://ieee802.org/16/password.html I'll ask IEEE to put the
240-page D3 up for sale, in place of D2. It should be in the catalog
in a few days <http://www.ili-info.com/ieee802drafts>. Thanks again to Chief
Technical Editor Itzik Kitroser. Itzik's Commentary database,
including editor's notes, is posted: <http://ieee802.org/16/docs/05/80216-05_021r3.zip> Itzik appreciated the
assistance of Marcos Vasconcellos, a colleague of Jon Labs. Working Group Recirc Ballot #17b,
with this draft under review, will follow. Cheers, Roger -- Dr. Roger B. Marks
<mailto:marks@nist.gov> +1 303 497
7837 National Chair, IEEE 802.16 Working Group
on Broadband Wireless Access |