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

Re: [STDS-802-16] release of P802.16-2004/Cor1/D3



Title: RE: [STDS-802-16] release of P802.16-2004/Cor1/D3
Maybe Sean Kai  can edit the next version ????
-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]On Behalf Of Jonathan Labs
Sent: May 25, 2005 6:57 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] release of P802.16-2004/Cor1/D3

Jungnam, Sean, et al.
 
In Itzik's defence, editing the draft is a big job.  I don't think anyone disagrees on that issue.  But as he pointed out, we often create comments which conflict or contradict each other or existing text.  Part of his job is to sort out these problems when incorporating accepted comments, from an editorial view.  He is not allowed to make technical decisions when editing a new draft.  I understand that some of his decisions, however, may be viewed by other members as technical decisions.  
 
The project is not finished, and this is not the final draft.  But in the interest of finishing it in a timely manner, I would ask that we move forward and resolve this by you submitting a new comment during the Sponsor Ballot.  
 
Thanks,
Jon  


From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Sean Cai
Sent: Tuesday, May 24, 2005 3:17 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] release of P802.16-2004/Cor1/D3

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,

Sean Cai

ZTE San Diego, Inc.
10105 Pacific Heights Blvd., Suite 250
San Diego, CA 92121

Tel: 858-554-0387 x212
Fax: 858-554-0894

 

-----Original Message-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Jungnam Yun
Sent:
Sunday, May 22, 2005 11:23 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] release of P802.16-2004/Cor1/D3

 

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-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG] On Behalf Of Itzik Kitroser
Sent:
Monday, May 23, 2005 2:42 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] release of P802.16-2004/Cor1/D3

 

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
Sent:
Sunday, May 22, 2005 5:35 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] release of P802.16-2004/Cor1/D3

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-----
From: owner-stds-802-16@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16@LISTSERV.IEEE.ORG]
On Behalf Of Roger B. Marks
Sent:
Sunday, May 22, 2005 12:32 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: [STDS-802-16] release of P802.16-2004/Cor1/D3

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 Institute of Standards and Technology/Boulder, CO, USA

Chair, IEEE 802.16 Working Group on Broadband Wireless Access

        <http://WirelessMAN.org>


CONFIDENTIALITE : Ce message et les éventuelles pièces attachées sont confidentiels. 
Si vous n'êtes pas dans la liste des destinataires, veuillez informer l'expéditeur immédiatement
et ne pas divulguer le contenu à une tierce personne, ne pas l'utiliser pour quelque raison que
ce soit, ne pas stocker ou copier l'information qu'il contient sur un quelconque support.

CONFIDENTIALITY : This  e-mail  and  any attachments are confidential and may be privileged. 
If  you are not a named recipient, please notify the sender immediately and do not disclose the
contents to another person, use it for any purpose or store or copy the information in any medium.