Re: [802SEC] Heads-up on upcoming motion to forward 15.2 D9 to RevCom
Bob,
Speaking as a RevCom member, I think some eyebrows would go
up if we received a submittal of an RP where the sponsor (Paul)
sustained a negative. This kinda thing is usually a "red flag"
at RevCom.
Having read through Paul's comment and the BRC's response,
it appears that you just might be able to convince him to
change his vote to affirmative. This would certainly make
your submittal package cleaner.
Howard
Bob Heile wrote:
> 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
>
>