RE: stds-802-16: 802.16ab-01/01r1 published; Final Task Group Rev iew in progress
Ken,
Thanks for your letter.
Let me make few comments about " ... plus the approved comments from session
#14."
MAC-PHY section for OFDM obviously falls into this category.
You say "This was editorial. Omissions like this ...."
But, excuse me, this is exactly the point. There is some boundary for the
editorial omissions
(can an editor omit the whole text?). The topics ARQ and MAC-PHY OFDM would
constitute
~ 30% of the MAC text if were not omitted.
Sorry for not supplying ARQ pictures (I'll send them shortly), but in this
case a picture may be replaced with a placeholder
as it often happened in TG1. A reason of this sort may be found for each
section.
Whatever are the explanations, these two sections were taken out without an
explicit decision of the group.
I didn't expect this to happen.
Vladimir
> -----Original Message-----
> From: Ken Peirce [mailto:ken@Malibunetworks.com]
> Sent: Monday, August 06, 2001 9:48 PM
> To: Vladimir Yanover; Roger B. Marks (E-mail); Brian G.
> Kiernan (E-mail); 802. 16 Reflector (E-mail)
> Subject: RE: stds-802-16: 802.16ab-01/01r1 published; Final
> Task Group Rev iew in progress
>
>
> Vladimir,
>
> > Is it correct that 01/01r1 document was supposed to accommodate the
> > resolutions of Session #14?
> >
> > I look at MAC part and see that a lot of things were taken
> > out without any relation to comments.
> > For example, the whole ARQ section. There were no comments on
> > taking out the whole section.
> > Opposite, there was a decision of MAC group to approve
> > block-based numbering (that constituted about
> > 50% of the whole text) and delete MPDU-based numbering ( a
> > single subsection of ARQ in 01/01 doc, which
> > contained three lines and one picture).
>
> There are comments that cited problems in the block numbering scheme
> pictures.
> You agreed to fix them. When looking at the editing process
> as a whole, we
> resolved to adopt
> the block-based scheme section, with corrected images which were not
> available at the time of the adoption.
>
> > ARQ Ad Hoc was created to add to ARQ section a description of
> > ARQ ALGORITHM
> > (State Machines),
> > i.e. just to fill empty subsection 6.4 of 01/01 doc, not for
> > rewriting all the section. Another goal is to change
> > certain structures (ACKs etc.)
>
> From the draft TG3 minutes:
>
> "The motion is reflected as follows:
> To adopt the MAC portion of the 80216ab-01/0/1 document
> including session
> #14 resolutions as placeholders for the relevant future text, plus the
> approved comments from session #14."
>
> I believe that it is clear that to include the resolutions as
> placeholders
> means, in the case of the block-based numbering text, to include the
> resolution that it would be the numbering scheme used. All
> that is needed is
> a comment that contains the original text, corrected images and ad hoc
> resolved(see below) text.
>
> > At Page 33 of 01/01r1 we find a list of Session #14
> > resolutions including
> > "MAC document must specify the numbering
> > scheme ... " etc. I am sorry, it was NOT a decision of the
> group. The
> > decision was to choose one of the schemes
> > (namely block-based) of two ALREADY PRESENT in the 01/01 and
> > to reject the
> > second.
>
> You are correct that the numbering scheme in the document is to be
> preserved/used/adopted. The wording of the resolution as
> presented in the
> document is not exact - my fault. It is stated accurately the
> minutes, which
> I am waiting for Durga to approve. Considering the last
> meeting, he has the
> right to look at them for quite a while before approving them.
>
> >
> > Were the motions passed at the MAC meeting published as
> > "Minutes"? If no
> > (seems, this is the case), how does it
> > fit the IEEE procedure when all the motions should be
> > published in "Minutes"
> > and "Minutes" should be approved by voting?
> >
> > Another example is the resolution of the Comment #80 that
> > addresses to the
> > section 8.3.4.4 and requests
> > "Insert the text from the document "802.16abc-01/03" by
> > V.Yanover". The
> > resolution was "Accepted-Modifed" and
> > the modification was specified as follows:
> >
> > "Not approved:
> > 1. Section 8.3.4.4.5.1 Synchronization Field:
> > Frame Duration
> > Code
> > 2. Section 8.3.4.4.3 Minislot definition
> > (These two subsections were tabled: "Rejected sections under
> > examination.
> > MAC/PHY ad hoc will provide a resolution.")
> >
> > Thus the rest of material has had to be accommodated into
> the document.
> >
> > But the section 8.3.4.4 in 01/01r1 appears empty.
> >
> > I believe that these are editorial mistakes and they may
> be corrected
> > editorially.
>
> This was editorial. Omissions like this can be brought to the
> editor or
> group with a comment and they will be corrected.
>
> >
> > Some SC specific MAC topics are present and some are not without any
> > relation to comments.
> >
>
> Could you clarify this? The joint TG3/TG4 MAC group resolved
> to add new
> subclause headers at the last meeting for
> the 3 different PHYs within a specific frequency band. I did
> not duplicate
> text and place it in each section. I expect to get comments
> which would
> request a modified replication appropriate to be filled in
> the particular
> PHY subclause. There was no editorial guidance offered by the
> MAC group as
> to how to handle this issue so I made a call.
>
> > Similar incident has happened already with Runcom OFDMA stuff
> > (before the
> > Session #14).
> >
>
> This happened in a draft of the first merged document. The
> observation of
> the omission was placed in the comments and the
> comment was summarily approved.
>
> > I think, at this point we don't need more proof that there is
> > a serious
> > problem with our procedures in MAC editorial
> > activity and even in writing a minutes. This really is
> going too far.
> > Situation when the editorial team takes the topics in and
> out without
> > any legal procedure is not acceptable.
> >
>
> The TG3 minutes issue at the last meeting occurred because
> the plenary went
> so far overtime that the TG3 group could not meet to
> approve/disapprove the
> minutes prior to their citation by folks during the joint PHY
> session that
> (IMO incorrectly)followed.
>
> I am puzzled/disappointed by your statement that the editorial team
> illegally/maliciously removed or introduced topics at an open-to-all
> meeting.
>
> > My understanding is that there should not be any way to
> > change the document
> > other than a resolution of the specific comment.
> > Can I ask, is it correct?
> > Some people at the last meeting expressed opinion that it is
> > a faster way to
> > go forward to jump over procedural issues.
> > For example, MAC part of the 01/01r1 document was voted while
> > not existed in
> > any form.
> > Let me remind that at MAC group at least one day was wasted for the
> > discussion on the issues that were actually
> > just an implication of incorrect assembling of 01/01 document
> > (MAC part).
> > After investing a lot of time into consolidation
> > of ARQ material and OFDM related MAC issues, we may meet at
> > the next session
> > with nothing, and all the consolidation
> > has to be restarted. Seems that the next meeting will start the same
> > counterproductive way.
> >
> > Vladimir
> >
>
> I agree with you on the vote. The problem created by approval of the
> document in absentia is that there was no ability to float a
> draft version
> to catch omissions or discuss the interpretation of text.
> I don't agree that we are back to nothing for the document
> text. I will
> publish a detailed agenda in advance for this meeting. I plan
> to go through
> the document section-by-section during the session #15
> meeting. We will vote
> then and there to include/modify/correct text - and work to
> provide the
> text. Up until now, with the prior MAC/PHY merging and the
> structural and
> options changes made at this meeting, we could not really be
> productive in
> attempting this. The document was "too raw", as Lei would
> say. The document
> appears to be stable from a framework point of view now.
>
> Also, I have asked the two chairs to create clause editor
> positions. This
> would spread out the work and increase the speed and accuracy of
> modifications. Please send them email to encourage them on this.
>
> With regards to having text that can be placed in the framework, I am
> curious as to when the MAC/PHY ad hoc will start? It would be
> helpful if
> text could be created and discussed by the group prior to the
> meeting so
> that we could adopt it without controversy at the next meeting.
>
> Cheers,
> Ken
>
>