| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
I have also noticed that the draft P802.20-D0.1m was inadequate for balloting. Firstly, as the current draft D0.1m (D3.0) is an update to the previous draft (D2.1), the changes to balloted D2.1 should have been tracked, so that the impact to the previous balloted version of the standard draft can be seen clearly.
Secondly, it was noted from the draft that the text for the TDD mode was incomplete. It is a problem as the decision of the WG during the March meeting was to modify the TDD text so that it became consistent with the newly adopted FDD (UMB) technology. Furthermore, the removal of additional partitioning that is previously supported by D2.1 is not appropriate.
Thirdly, some technical changes have been noted as the UMB text was incorporated into the draft P802.20-D0.1m. For example, the support of FFT sizes 128, 512 and 1.25 MHz bandwidth in UMB has not been included in the draft P802.20-D0.1m. These changes may not be compliant with the WG decision in the March meeting - to adopt UMB for the FDD mode.
Therefore, the current draft P802.20-D0.1m is not adequate and not ready for the practice ballot. As a member of the editorial team, I would like to bring this to the attention of the WG members.
Currently, I plan to work with the other editorial team members on a new draft that would be adequate for balloting.
Best regards,
Anna.
From: Oprescu Val-A10289
[mailto:voprescu@MOTOROLA.COM]
Sent: Wednesday, May 02, 2007 4:05 PM
To: STDS-802-MOBILITY@listserv.ieee.org
Subject: [802-20-GENERAL:] PLB on current draft (04/11/07) D0.1m
Dear 802.20 associates:
As we all are aware, at the March 2007 meeting, an Editorial Group, that includes me as a member, was established to produce a draft specification based on C802.20-07-27. The goal was to have the draft form the base of a 30-day practice letter ballot to commence on 04/11/2007.
Unfortunately, there have been issues in the Editorial Group including lack of timely communication between members, apparently divergent expectations, unconventional editorial practices, disputed membership and insufficient time.
The net result has been a draft document that, in my judgment, is not ready and is not appropriate to form the basis, even for a first and informal ballot, as the Practice Letter Ballot is claimed to be. On 04/06, I made my position clear to the members of the editorial group, together with explicit and detailed reasons, pointing to specific sections and text within the draft specification.
My April 6, 2007 reply to Mark Klerer’s e-mail is enclosed at the bottom of this message, as it explicitly indicates issues, by section. In short, it raises two main concerns:
1) Lack of revision marks to enable back traceability to the sources of text that are supposed to feed the draft and to enable a way of distinguishing between those sources and the modifications that the Editor performed; and
2) Silent (i.e.unmarked) changes in selected technical functionality, which, in my judgment, should not happen in an editorial merger, but be subject to explicit technical discussion via contributions presented in front of the entire working group.
Nevertheless, the draft was submitted to the Practice Letter Ballot, without the necessary corrections, despite those obvious flaws. This is particularly regrettable, since it should have been obvious that consensus in the Editorial Group to release the document has been lacking, fact confirmed last week when the Editorial Group finally managed to hold its first meeting. (A poll taken on whether the document is ready to form the basis of the Practice Letter Ballot indicated the group split in the middle).
For the last two weeks I have tried
to convince Arnie and the Editorial Group that it would be unadvisable to
proceed with a Practice Letter Ballot on the current draft, given the
situation. Instead, I have suggested that we work on a replacement draft that
corrects the indicated shortcomings; and that we produce this new draft in time
for it being presented and hopefully approved at the
Therefore, I find it hard to
participate in the 04/11-05/10 Practice Letter Ballot and to submit any
comments on a draft that I consider too flawed to form a basis for comments.
Instead I will try to use my time and energy in the Editorial Group, for the
production of the replacement draft, as described above. I hope that such a
draft can be agreed by 802.20 WG in
Regards,
Val
Text of my 04/06/07 message to Mark Klerer (cc’ed to the Editorial Group and to Arnie) follows:
Mark:
I have been reviewing your draft and I have also consulted with some of my colleagues that are involved with 802.20 related work. In short, at this point, I cannot agree with the current version, as is, to become the base for the practice ballot.
This is not criticism of your editorial skills, but as you might recall, I mentioned to you during the meeting that an appropriate merger in such a short time may be very difficult to complete.
The crux of the issue is that the submitted draft contains technical changes (many related with TDD features vis-à-vis UMB) that go beyond an editorial mandate. While I think that it is good that you tried to propose technical solutions, those solutions should be treated as technical proposals subject to WG approval.
For example, one concern is related to the apparent disappearance of non 1:1 partitions in the TDD mode and with text (section 4.6.7.4.1.2.4.2) that seems to limit the use of group resource allocation in TDD. Another example consists of a specific way of signaling for TDD in Table 31, which may be a way to do it, but it may not be the only way.
Another issue is “back trackability” of the draft to source documents. It is very important to be able to show each piece of text where it originated from. While for some parts is quite clear (e.g. UMB, MC625k), for the TDD part there should also be a clear place where the text itself (not only the concept) originates. I looked in version D2.0 and D2.1 and textual mapping was not obvious to me. When you add/delete stuff for “gluing” TDD into the UMB, the “glue” should be explicitly redlined as a proposed way of gluing, subject to discussion. Also, for changes that are not TDD related, for example the removal of two columns from Table 126, the proper way is to show the original with strikethrough marks, such that everyone can see what exactly is being removed.
As you recall, I support not having a full redlined document as impractical, but the changes that the editor makes as "glue" should be fully redlined. Lack of these markings slowed down my review process significantly, to the point that I have not yet completed reviewing the document.
It is also necessary to see how the 802.20 text from the approved spec as of the pre-March meeting was used: in other words what was fully replaced and what was moved to the new spec. Did we miss anything in the process ? What version did you use?
Especially given the history of 802.20, taking a lot of editorial license may cause some frictions that can be avoided by a more narrow adherence to process.
To make progress, I suggest you set up a conference call of the editorial group for Monday 04/09 or Tuesday to see whether we can solve these issues.
As you know, the editorial draft will become the de-facto baseline against which comments will be written and those comments will have to meet the high threshold needed for approval. Therefore it is very important that the baseline is un-impeachable and fully agreed upon, before the practice ballot can start.
Best Regards,
Val