| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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