Re: [STDS-802-16] +++Voting Process on Approval of P802.16-REVd/D5 Recirculation Comments Now Open; Deadline of 5 June
Hi Roger, all,
After reading the possibilities below, I am convinced that there are ways to
correct the errors I identified in rev-D5, such that publication is not
delayed.
I would therefore request the BRC voters to reject all my comments.
Regards,
Yigal
-----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: Thursday, June 03, 2004 10:59 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] +++Voting Process on Approval of P802.16-REVd/D5
Recirculation Comments Now Open; Deadline of 5 June
David,
On one hand, I wouldn't worry that the 16e PAR scope prohibits us
from making corrections that are not directly related to mobility.
According to IEEE-SA, an amendment is "a document that has to contain
new material to an existing IEEE standard and that may contain
substantive corrections to that standard as well." In my experience,
IEEE-SA allow errata in an amendment, even when it isn't explicit in
the PAR scope. For example, 802.16a corrected errors in 802.16-2001.
Also, we are proposing to modify the 16e PAR and could easily add a
sentence about errata. Let's consider that as alternative (1).
On the other hand, I do see merits in your arguments. I would suggest
that we consider the following two alternatives:
(2) Add errata to the scope of the upcoming MIB PAR that we agreed on
in Shenzhen. That would make a lot of sense, especially if we expect
that MIB work to be complete soon. After all, that PAR is targeted at
fixed-only.
(3) We could open a PAR for a corrigenda ("Corrigenda: A document
that only contains substantive corrections to an existing IEEE
standard.") This kind of PAR does not require 30-day advance notice
to the SEC.
Even if we don't know of any errors in the final version of REVd, I
can confidently predict that we will find some. Therefore, for
protection, we need to identify a specific outlet for the
corrections. We can, and we should, make the decision at Session #32.
At the moment, (2) and (3) sound like the best options.
Thanks for your input.
Roger
At 17:02 +0100 04/06/03, David Castelow wrote:
>Roger,
>
>I raised this issue at the plenary in Shenzhen, but your comment to
>Vladimir brings it to mind once more.
>While the .16e PAR provides the opportunity to make amendments, can you
>please provide guidance as to how we can distinguish which parts of the
>contents of the .16e document are corrections to .16-2004 and which are
>the additional features required to implement .16e. Is the PAR really
>sufficient to provide for errata? I quote from the current PAR
>document:
>
>Scope of Proposed Project:
>This document provides enhancements to IEEE Std 802.16/802.16a to
>support subscriber stations moving at vehicular speeds and thereby
>specifies a system for combined fixed and mobile broadband wireless
>access. Functions to support higher layer handoff between base stations
>or sectors are specified. Operation is limited to licensed bands
>suitable for mobility between 2 and 6 GHz. Fixed 802.16a subscriber
>capabilities shall not be compromised (See Item #18).
>
>A strict, narrow, interpretation of this would not seem to allow any
>errata to be included.
>
>Also the errata MUST be made explicit.
>In the case of .16c, the profiles were not in conflict with any changes
>to the base document.
>In .16e, large changes are likely to be made, and we need to distinguish
>the errata to .16-2004 from the other changes being made in .16e.
>
>At the very least, I suggest, and shall raise a comment to this effect,
>that a section of the .16e document be created in which the errata can
>reside.
>
>There is also the issue of timing. While the current plan shows .16e
>completing around November, given the changes currently being
>introduced, this seems optimistic. Some of the technical issues being
>discussed for .16-2004 (aka .16-REVd/D5) need rapid agreement, in order
>for ASICs to be constructed in a timely fashion.
>
>However, this does not resolve marketing style issues relating to
>compliance (to what: " .16-2004 plus the Errata Section of .16e" is a
>bit of a mouthful).
>
>The alternative of creating an Errata document would be preferable.
>
>Comments please.
>
>Regards
>
>David Castelow
>
>
>-----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: 03 June 2004 14:37
>To: STDS-802-16@LISTSERV.IEEE.ORG
>Subject: Re: [STDS-802-16] +++Voting Process on Approval of
>P802.16-REVd/D5 Recirculation Comments Now Open; Deadline of 5 June
>
>Vladimir,
>
>We are at the end of the line, and time is too short for reply comments.
>People have had one chance after another to get their comments right. If
>a comment isn't right, then I think you should vote to reject. If you
>think there is a valid point here, then we should use the amendment
>mechanism to address it. Fortunately, we have an active amendment
>project - P802.16e - in which to include any additional changes.
>
>Roger
>
>
>At 15:25 +0300 04/06/03, Vladimir Yanover wrote:
>>Roger,
>>
>>There are useful comments in database, in which remedy is incomplete or
>
>>contains errors.
>>If we reject them, the problem stays, if accept, the text becomes
>>inconsistent.
>>Is there a procedural way to modify suggested remedy?
>>In D4 we had step of reply comments and it was very useful
>>
>>Thanks
>>
>>Vladimir
>>
>>-----Original Message-----
>>From: Roger B. Marks [mailto:r.b.marks@ieee.org]
>>Sent: Wednesday, June 02, 2004 7:17 AM
>>To: stds-802-16@ieee.org
>>Subject: +++Voting Process on Approval of P802.16-REVd/D5 Recirculation
>
>>Comments Now Open; Deadline of 5 June
>>
>>
>>When I posted the P802.16-REVd/D5 Recirculation comments, I said that I
>
>>would announce the on-line comment resolution process in a few days and
>
>>told you to expect the decision-making process to be quick. I hope you
>>have had time to read the comments.
>>
>>The process is described in IEEE 802.16-04/31
>><http://ieee802.org/16/docs/04/80216-04_31.pdf>. Members of the IEEE
>>802.16 Working Group <http://ieee802.org/16/members.html> are the
>>members of the Ballot Resolution Committee and eligible to vote. They
>>should read IEEE 802.16-04/31 for details. It explains the need to make
>
>>a quick decision on these comments.
>>
>>The voting deadline is 5 June AOE.
>>
>>Regards,
>>
>>Roger
>>
>>
>>
>>>The P802.16-REVd Recirc #2 balloting period has closed.
>>>
>>>The good news is that we are down to one Disapprove voter (Nico van
>>>Waes). He submitted one Technical Binding comment, which was a
>>>reiteration of a previous comment.
>>>
>>>The bad news is that we received a total of 171 comments.
>>> http://ieee802.org/16/docs/04/80216-04_30.zip
>>>
>>>The following show the members of the Sponsor Ballot Group who
>>>submitted comments, along with the number of comments:
>>>
>>>Tal Kaitz 2
>>>Itzik Kitroser 11
>>>Yigal Leiba 44
>>>Cor van de Water 3
>>>Nico van Waes 1
>>>
>>>I received additional comments from other individuals who do not
>>>belong to the Sponsor Ballot Group:
>>>
>>>Raja Banerjea 3
>>>Changhoi Koo 68
>>>Lalit Kotecha 14
>>>Wonil Roh 25
>>>
>>>
>>>We will now move on to an on-line comment resolution process in which
>>>the members of the Ballot Resolution Committee will be the Members of
>>>the IEEE 802.16 Working Group. I will provide details in a few days.
>>>Expect the decision-making process to be quick.
>>>
>>>For those of you who are wondering where this leaves us: we have met
>>>the RevCom conditions for D5 to be approved as an IEEE standard on
>>>24 June. If we reject all of these comments, no further recirculation
>>>will be necessary. However, we also have the option to
>> >accept comments, produce draft D6, open a third recirculation, and
>> >remove D5 from the June RevCom agenda.
>> >
>> >Roger
>>
>>
>>This mail passed through mail.alvarion.com
>>
>>***********************************************************************
>>*****
>>********
>>This footnote confirms that this email message has been scanned by
>>PineApp Mail-SeCure for the presence of malicious code, vandals &
>>computer viruses.
>>***********************************************************************
>>*****
>>********
>>This mail was sent via mail.alvarion.com
>>
>>***********************************************************************
>>************* This footnote confirms that this email message has been
>>scanned by PineApp Mail-SeCure for the presence of malicious code,
>>vandals & computer viruses.
>>***********************************************************************
> >*************