[802SEC] Heads-up on upcoming motion to forward 15.2 D9 to RevCom
Here is a little change of pace for the reflector
I just wanted to give you guys a heads up that later this week I will be
making a motion to forward 802.15.2 Draft 9 to RevCom in time for
the May 2 cut-off for the June meeting. The reason I did not seek a
Procedure 10 in Dallas was the initial sponsor ballot had not closed at
that time. It needed to be extended 10 days to get the required
returns and since I did not know whether there would be additional no's
and of what type, it did not seem appropriate to go for a Procedure 10 at
that time.. It turned out there were no more negative votes than
the two we had already received prior to the Dallas meeting. These
we dealt with in Dallas and started a 15 day recirculation which closes
on April 15. At this point, it looks like it will be clean. Given
that this recommended practice could have some real value in the
coexistence arena, I would just as soon not have to wait another cycle of
RevCom meetings to get this thing out of Dodge.
The result of the initial ballot was:
1. This ballot has met the
75% returned ballot requirement.
66 eligible people in
this ballot group.
46 affirmative votes
2 negative votes with comments
0 negative votes without comments
7 abstention votes
=====
55 votes received = 83% returned
12% abstention
2. The 75%
affirmation requirement is being met.
46 affirmative
votes
2 negative votes with comments
=====
48 votes = 95% affirmative
The 2 negative votes we had received before the
Dallas meeting and we were able to deal with them there. Both were
rejected and classified as non-Technical. These are both being
recirculated with Draft 9. Assuming nothing new, we are done and I
will be seeking approval to go forward.
For reference the comments made on Draft 8 were:
CommenterName CommentType
CommentID
Clause Subclause Page Line
Nikolich,
Paul T
9
00
00 00 00
Comment
There are many instances
where the document refers to "IEEE 802.11b" (strictly speaking,
the 802.11 Higher Speed PHY Extension in the 2.4 GHz band) when it really
means to call out the combination of the 802.11-1999 MAC and the
802.11b-1999 (for example the second sentence in section 1. Overview).
Thus the nomenclature used is misleading and confusing and will become
even more confusing when the specifications contained in the 802.11b-1999
amendment is folded into a new edition of the 802.11 document.
802.11b will then no longer be a valid document, but the specification
will remain valid, alive and well, a clause in the new edition.
One way to eliminate confusion may be to call 802.11-1999 by a unique
abbreviated name "802.11 WLAN MAC" and 802.11b-1999 by a unique
abbreviated name "802.11 WLAN 2.4GHz Higher Speed PHY
Extension" and an instantiation of the combination of the two a
"802.11 WLAN 2.4GHz Higher Speed Data Link"---or something
simillarly appropriate. I hope I am being clear.
What I am striving for is for the document to use a system of
nomenclature that is unambiguous and clear, perhaps something similar to
that used in 802.3, where it is clear from the naming conventions used
that 10BaseT, 100BaseT and 1000BaseT are all different speed versions of
a twisted pair PHY, that are independent of the arbitrary 802.3* project
name given to them at the time of their creation.
suggested_remedy = Make it clear when you are refering to a 802.11
MAC/PHY Data Link implementation based on the 802.11-1997 and
802.11b-1999 specifications. My recommendation is you give this
combination of specifications a unique name (as suggested above: 802.11
WLAN 2.4GHz Higher Speed Data Link) and clearly define it in the
definitions section.
SuggestedRemedy
Make it clear when you are
referring to a 802.11MAC/PHY Data Link implementation based on the
802.11-1997 and 802.11b-1999 specifications. My recommendation is you
give this combination of specifications a unique name (as suggested
above: 802.11 WLAN 2.4GHz Higher Speed Data Link) and clearly define it
in the definitions section.
Response
REJECT.
This comment is out of scope, since we have no control over the naming of
the 802.11 future standard. Currently, it is well understood that 802.11b
implies the physical layer extension and the 802.11 MAC sub-layer. Future
proofing of this draft for another different future draft is not always
possible. This problem was created by a failure to follow IEEE 802
procedure to renew the 802.11 draft when multiple amendments were
created. BRC does not consider this a technical comment on the draft,
since it is referencing (an editorial matter) normative standards and
future versions of it.
CommenterName CommentType CommentID
Clause
Subclause
Page
Line
O'Farrell, Timothy
T 8 D
89
Comment
The source code of
Appendix D is provided without a flow diagram schematic. To enhance
understanding and accessibility of the program material a flow diagram
schematic is required.
SuggestedRemedy
Include a flow diagram
schematic of the source code presented in Appendix D.
Response
REJECT.
The BRC does not know of any requirements to supply a flow diagram for
code, therefore one will not be created and included. BRC does not
consider this a technical comment on the draft, since it relates to a
informative annex.
Bob Heile, Ph.D
Chair, IEEE 802.15 Working Group on Wireless Personal Area
Networks
Chair, ZigBee Alliance
11 Louis Road
Attleboro, MA 02703 USA
Phone: 508-222-1393
Mobile: 781-929-4832
Fax:
508-222-0515
email: bheile@ieee.org