Re: [802SEC] +++EC Email ballot (closes no later than 25SEP2006)+++ Motion to approve the attached EC SC6 recommendation+++tentative result on v10
I am ok with v11 as well
At 06:26 AM 9/25/2006 -0700, Gupta, Vivek G wrote:
>Approve v11
>
> > -----Original Message-----
> > From: ***** IEEE 802 Executive Committee List ***** [mailto:STDS-802-
> > SEC@ieee.org] On Behalf Of Paul Nikolich
> > Sent: Monday, September 25, 2006 3:32 AM
> > To: STDS-802-SEC@listserv.ieee.org
> > Subject: [802SEC] +++EC Email ballot (closes no later than
>25SEP2006)+++
> > Motion to approve the attached EC SC6 recommendation+++tentative
>result on
> > v10
> >
> > Tony,
> > Thank you for endorsement of V11 and agreement to submit either V10 or
>V11.
> >
> > EC Members,
> > The ballot closes today. The only members that have cast an 'opinion'
>on
> > V11 are Tony, Roger and Geoff. If the majority of the EC cast
>approves
> > votes on V11 while the ballot remains open until the end of today
>25SEP, I
> > will submit V11 to Robin Tasker as the 802 recommendation, otherwise I
> > will submit V10.
> > Regards,
> > --Paul
> >
> > -------------- Original message from Tony Jeffree
><tony@JEFFREE.CO.UK>: --
> > ------------
> >
> >
> > > G'day Andrew -
> > >
> > > I would agree that V11 is an improvement, but would also be happy
>going
> > > with V10 if time constraints don't permit.
> > >
> > > Paul -
> > >
> > > As Andrew says, its up to you - if you want to have an instant
>re-run of
> > > the vote for V11, I am happy to accept V11 as a friendly amendment,
>and
> > to
> > > vote "Approve" on it. Alternatively, I am happy to stick with V10 if
> > that
> > > is what you think the time constraint dictates.
> > >
> > > Regards,
> > > Tony
> > >
> > > At 05:49 25/09/2006, Andrew Myles (amyles) wrote:
> > > >G'day Paul,
> > > >
> > > >I agree with Roger that v11 is incrementally better than v10.
>However,
> > > >you now "have the conch" (from Lord of the Flies) on how to handle
>the
> > > >next step. Maybe the EC members could quickly vote on v11? Or maybe
>you
> > > >could send v10, quickly followed by v11 as a clarification?
> > > >
> > > >The absolute drop dead date for getting the input to Robin is 27
>Sept.
> > > >However, I am not sure where in the world the date is measured.
>Could
> > be
> > > >Geneva (ISO HQ), Seoul (SC6 Secretariat), UK (Robin Tasker's home),
>or
> > > >somewhere else. Geoff, do you know?
> > > >
> > > >Andrew
> > > >
> > > >
> > > >________________________________
> > > >
> > > >From: Roger B. Marks [mailto:r.b.marks@ieee.org]
> > > >Sent: Monday, 25 September 2006 2:40 PM
> > > >To: Andrew Myles (amyles)
> > > >Cc: STDS-802-SEC@listserv.ieee.org
> > > >Subject: RE: [802SEC] [802SEC] +++EC Email ballot (closes no later
>than
> > > >25SEP2006)+++ Motion to approve the attached EC SC6
> > > >recommendation+++tentative result on v10
> > > >
> > > >
> > > >Thanks, Andrew. I'm mostly happy with your suggestions. I don't
>fully
> > > >agree with everything, but I would vote Approve on v11.
> > > >
> > > >
> > > >I really think we should go with v11 instead of v10. If you read
>the
> > > >documents in full, they are pretty close. However, v11 is pretty
>v10 is
> > > >not fully self-consistent, especially where headlines don't exactly
> > > >match the content. We have in the past seen cases in which a
>national
> > > >body has taken pieces of IEEE contributions out of context and made
>it
> > > >look as if we are saying something that we did not intend. v10
>would
> > > >make that too easy.
> > > >
> > > >
> > > >Roger
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >G'day Paul,
> > > >
> > > >I have processed Roger's comments into a v11 and have attached v11
>with
> > > >changes marked in red, and a clean version. You already have a
>clean
> > > >v10. Most of Roger's suggestions improve the document, although I
>have
> > > >modified a few of his suggestions. He will need to respond with his
> > > >approval of my changes.
> > > >
> > > >I have no idea how you want to handle this late change procedurally
> > > >given that the document is due to Robin Tasker on the 27 Sept.
> > > >Personally, I believe either v10 is good enough but v11 is slightly
> > > >better and clearer. .
> > > >
> > > >Andrew
> > > >
> > > >BTW I assume that you will be sending the document to Robin?????
> > > >
> > > >
> > > >________________________________
> > > >
> > > >
> > > >RM> I'm sorry that other commitments have kept me disengaged from
>this
> > > >discussion until now. Nevertheless, I am voting with four days
>still
> > > >left in the ballot period and hope for consideration of my
>comments.
> > > >
> > > >Considered below
> > > >
> > > >RM> I am voting Disapprove. I very much appreciate Andrew's
>excellent
> > > >work and patience, as well as the valuable comments of my EC
>colleagues.
> > > >
> > > >Thanks ;)
> > > >
> > > >RM> However, I still see significant weaknesses with the proposal
>and
> > > >cannot vote to approve. However, I would vote Approve if my
>comments
> > > >were accepted. I have tried to make my explanations and remedies
>clear
> > > >and thorough. I have indicated that most of these comments are
> > > >editorial, but I still think they are substantive and (except where
> > > >noted) they are all part of my disapprove vote.
> > > >
> > > >See below
> > > >
> > > >RM> Comments:
> > > >
> > > >RM> (1) [Editorial] The Slide 11 title says "8802-1 should be
>modified
> > > >so that an ISO/IEC standard can always be achieved" is an
>inappropriate
> > > >title. Some would infer that this means we are insisting that all
>802
> > > >standards are adopted as ISO/IEC standards. Others would infer that
>it
> > > >is a statement that IEEE insists that the only acceptable process
>is
> > one
> > > >that guarantees that every 802 proposal into ISO/IEC is adopted.
>Either
> > > >way, this comes across as an arrogant approach that would inhibit
> > > >support within ISO/IEC. Furthermore, the title does not reflect the
> > > >content of the slide, which proposes much less demanding language.
> > > >That's why I call this comment editorial.
> > > >
> > > >It was certainly not the intent that all 802 standards be adopted
>as
> > > >ISO/IEC standards. The 802 WGs always have the choice as to whether
>of
> > > >not a particular standard should be adopted. This is made clear on
>pp
> > 16
> > > >(of attached, the page numbers have changed by one because history
>page
> > > >removed)
> > > >
> > > >RM> Remedy:
> > > >-Change "8802-1 should be modified so that an ISO/IEC standard can
> > > >always be achieved" to ""Process should be modified to encourage
> > > >adoption of endorsed standards as 8802-x standards".
> > > >-Make the same change on Slide 4.
> > > >
> > > >That said, your proposed language is fine with slight modification
>also
> > > >based on your comments below, "The agreement should allow the
>adoption
> > > >of endorsed standards as 8802-x standards"
> > > >
> > > >RM> (2) [Editorial] Slide 6 says "Are 8802-xx standards covered by
>IPR
> > > >statements made to 802?" But the term "IPR" is too broad here; the
> > > >correct word is "patents". Furthermore, no IPR statements are made
>to
> > > >802; instead, Letters of Assurance are filed with IEEE-SA.
> > > >
> > > >Agreed
> > > >
> > > >RM> Remedy:
> > > >-Change to "Are 8802-xx standards covered by patent Letters of
> > Assurance
> > > >made to IEEE-SA?"
> > > >
> > > >Changed to "Are 8802-xx standards covered by patent LoA's made to
> > > >IEEE-SA?"
> > > >
> > > >RM> -Likewise, everywhere on Slide 19, change "IPR" to "patent".
> > > >
> > > >Done, also on pp 11
> > > >
> > > >RM> -In the first use of "LoA" on Slide 19, change to "Letter of
> > > >Assurance (LoA)".
> > > >
> > > >Already covered by pp 2
> > > >
> > > >RM> (3) [Editorial] On Slide 13, "Specify only 802 has the
>authority to
> > > >make changes to the 8802-x versions of 802.x standards" is
> > inappropriate
> > > >from an ISO/IEC perspective. ISO/IEC cannot and will not grant to
>802
> > > >the right to change 8802 standards arbitrarily. Furthermore, the
>title
> > > >does not reflect the content of the slide, which proposes much less
> > > >demanding language. That's why I call this comment editorial.
> > > >
> > > >RM> Remedy:
> > > >-Change to "Specify that changes to the 8802-x versions of 802.x
> > > >standards require IEEE 802 concurrence"
> > > >-Make the same change in Slide 12.
> > > >
> > > >Done, your language is nicer
> > > >
> > > >RM> On Slide 18, change "Assuming 802 becomes the authority for all
> > > >changes to 8802-x standards" to "Assuming 802 has approval
>authority
> > for
> > > >all changes to 8802-x standards"
> > > >
> > > >Done
> > > >
> > > >RM> (4) [Technical, not required] The process described on Slide 16
>is,
> > > >in my view, awkward, redundant and impractical. I don't understand
>why
> > > >ISO/IEC should have to run one ballot to endorse the 802 standard
>and a
> > > >second ballot to adopt it as an 8802 standard. If we think the
>second
> > > >step is required, then we must think that the endorsement process
> > > >doesn't satisfy the needs. So why bother with in at all? It's a lot
>of
> > > >trouble, and it would force a long delay before adoption.
> > > >
> > > >Personally, I believe that "endorsement" is not enough. Who cares
>about
> > > >endorsement? Is endorsement enough under trade rules? If
>endorsement is
> > > >so great then why haven't we bothered with it in the past? Actually
> > this
> > > >is a complex issue that I would love to talk about with you at some
> > > >point - maybe in Dallas?
> > > >
> > > >RM> Remedy: I am not proposing a remedy at this time, because I
>think
> > > >that 802 is too far along with its decision-making process to
> > > >reconsider. If it were earlier in the process, I would suggest that
> > > >propose to endorse either the endorsement process or the adoption
> > > >process, but not both. Personally, I'd prefer a modified version of
> > > >endorsement.
> > > >
> > > >No change requested
> > > >
> > > >RM> (5) [Editorial] Slide 4 says "SC6 has started a review of the
>8802-
> > 1
> > > >cooperation agreement". This is not the whole story. 6N13127 is
>seeking
> > > >comments three items: 1. 6N11917: Procedures for ISO/IEC JTC1 SC6
>WG1
> > > >and IEEE 802 LMSC Cooperative Working 2. TR 8802-1:2001 3. All
>relevant
> > > >resolutions
> > > >
> > > >Correct, as noted on pp 7
> > > >
> > > >RM> Remedy:
> > > >-Change "SC6 has started a review of the 8802-1 cooperation
>agreement"
> > > >to "SC6, via 6N13127, is seeking comments on the method of
>cooperation
> > > >between SC6/WG1 and IEEE 802."
> > > >
> > > >Changed to "SC6 has started a review with all stakeholders of
>issues
> > > >related to cooperation with 802" to be consistent with comment
>below
> > and
> > > >resulting change
> > > >
> > > >RM> -Likewise: Change title of Slide 8 from "SC6 has started a
>review
> > to
> > > >resolve the problems with the 8802-1 cooperation agreement" to "SC6
>has
> > > >started a review to resolve the problems with the 802 cooperation".
> > > >
> > > >Changed to "SC6 has started a review with all stakeholders of
>issues
> > > >related to cooperation with 802"
> > > >
> > > >RM> (6) [Technical] My Comment 5 is related to a broader problem
>that
> > is
> > > >a bit harder to solve. Our document revolves around suggestions to
> > > >change 8802-1 so as to improve the process. But the request for
> > comments
> > > >doesn't force us to consider 8802-1 as the only venue for the
>process.
> > I
> > > >believe that 8802-1 is the wrong venue to describe the process. In
>my
> > > >view, 8802-1 was, from the start, an inappropriate place to define
> > > >procedures. It's a Technical Report, not a procedural agreement
>between
> > > >IEEE and ISO/IEC. There is no way, procedurally, to turn 8802-1
>into a
> > > >true agreement. There is, for instance, no place for IEEE to sign
>it.
> > > >
> > > >Good points
> > > >
> > > >RM> Remedy: I think it is too late to suggest an alternative type
>of
> > > >document to contain the process. However, we can at least stop
> > insisting
> > > >that 8802-1 be the right venue. If we make the following changes,
>we
> > > >will still be specifying the kind of process we want, but we won't
> > > >saying that process needs to be defined in 8802-1:
> > > >-On Slide 11, change "8802-1" to "Process" in the title -On Slide
>12,
> > > >change "8802-1 should..." to "Process should..."
> > > >-On Slide 13, change "8802-1" to "Process" in the title -On Slide
>13,
> > > >change "This requires 8802-1 to specify" to "This requires process
>to
> > > >specify"
> > > >-On Slide 14, change "8802-1" to "Process" in the title and in both
> > > >places in the Proposed resolution column -On Slide 15, change
>"8802-1"
> > > >to "Process" in the title -On Slide 16, change "8802-1" to
>"Process" in
> > > >the title -On Slide 16, change "modified process for 8802-1" to
> > > >"modified process"
> > > >-On Slide 17, change "8802-1" to "Process" in the title and in both
> > > >places in the Proposed resolution column -On Slide 18, change
>"8802-1"
> > > >to "Process" in the title and in the Proposed resolution column -On
> > > >Slide 19, change "8802-1" to "Process" in the title -On Slide 20,
> > change
> > > >"8802-1" to "Process" in the title and in the Proposed resolution
> > column
> > > >
> > > >I have accepted the spirit of your suggestion but changed it to
>"Any
> > > >agreement ..." rather than "Process ...".
> > > >
> > > >RM> (7) [Technical] Slide 21 says "8802-1 should not contain any
> > > >technical material". Likewise, Slide 12 says 8802-1 should "Not
>contain
> > > >any technical material." It's true that 8802-1 has both technical
>and
> > > >procedural content, and that's not good. But this proposal would
>remove
> > > >the wrong part. It really doesn't make any sense for us to
>recommend
> > > >that ISO/IEC maintain a "Technical Report" and insist that it be
> > without
> > > >technical content.
> > > >
> > > >I hope you agree that 8802-1 currently contains a lot of technical
> > > >information that does not need to be there. We need to remove this
>info.
> > > >Presumably the technical part of the technical report would be the
> > > >references to 8802.x and 802.x standards. There is no intent to
>remove
> > > >this
> > > >
> > > >RM> Remedy:
> > > >-On Slide 12, delete "Not contain any technical material"
> > > >-Delete Slide 21.
> > > >
> > > >I have softened the language. Have a look
> > > >
> > > >-----Original Message-----
> > > >From: owner-stds-802-sec@ieee.org
>[mailto:owner-stds-802-sec@ieee.org
> > > > ] On Behalf Of Roger B. Marks
> > > >Sent: Friday, 22 September 2006 3:28 PM
> > > >To: Paul Nikolich
> > > >Cc: STDS-802-SEC@listserv.ieee.org
> > > >Subject: Re: [802SEC] [802SEC] +++EC Email ballot (closes no later
>than
> > > >25SEP2006)+++ Motion to approve the attached EC SC6
> > > >recommendation+++tentative result on v10
> > > >
> > > >Paul,
> > > >
> > > >I'm sorry that other commitments have kept me disengaged from this
> > > >discussion until now. Nevertheless, I am voting with four days
>still
> > > >left in the ballot period and hope for consideration of my
>comments.
> > > >
> > > >I am voting Disapprove. I very much appreciate Andrew's excellent
>work
> > > >and patience, as well as the valuable comments of my EC colleagues.
> > > >However, I still see significant weaknesses with the proposal and
> > cannot
> > > >vote to approve. However, I would vote Approve if my comments were
> > > >accepted. I have tried to make my explanations and remedies clear
>and
> > > >thorough. I have indicated that most of these comments are
>editorial,
> > > >but I still think they are substantive and (except where noted)
>they
> > are
> > > >all part of my disapprove vote.
> > > >
> > > >Comments:
> > > >
> > > >(1) [Editorial] The Slide 11 title says "8802-1 should be modified
>so
> > > >that an ISO/IEC standard can always be achieved" is an
>inappropriate
> > > >title. Some would infer that this means we are insisting that all
>802
> > > >standards are adopted as ISO/IEC standards. Others would infer that
>it
> > > >is a statement that IEEE insists that the only acceptable process
>is
> > one
> > > >that guarantees that every 802 proposal into ISO/IEC is adopted.
>Either
> > > >way, this comes across as an arrogant approach that would inhibit
> > > >support within ISO/IEC. Furthermore, the title does not reflect the
> > > >content of the slide, which proposes much less demanding language.
> > > >That's why I call this comment editorial.
> > > >
> > > >Remedy:
> > > >-Change "8802-1 should be modified so that an ISO/IEC standard can
> > > >always be achieved" to ""Process should be modified to encourage
> > > >adoption of endorsed standards as 8802-x standards".
> > > >-Make the same change on Slide 4.
> > > >
> > > >(2) [Editorial] Slide 6 says "Are 8802-xx standards covered by IPR
> > > >statements made to 802?" But the term "IPR" is too broad here; the
> > > >correct word is "patents". Furthermore, no IPR statements are made
>to
> > > >802; instead, Letters of Assurance are filed with IEEE-SA.
> > > >
> > > >Remedy:
> > > >-Change to "Are 8802-xx standards covered by patent Letters of
> > Assurance
> > > >made to IEEE-SA?"
> > > >-Likewise, everywhere on Slide 19, change "IPR" to "patent".
> > > >-In the first use of "LoA" on Slide 19, change to "Letter of
>Assurance
> > > >(LoA)".
> > > >
> > > >(3) [Editorial] On Slide 13, "Specify only 802 has the authority to
> > make
> > > >changes to the 8802-x versions of 802.x standards" is inappropriate
> > from
> > > >an ISO/IEC perspective. ISO/IEC cannot and will not grant to 802
>the
> > > >right to change 8802 standards arbitrarily.
> > > >Furthermore, the title does not reflect the content of the slide,
>which
> > > >proposes much less demanding language. That's why I call this
>comment
> > > >editorial.
> > > >
> > > >Remedy:
> > > >-Change to "Specify that changes to the 8802-x versions of 802.x
> > > >standards require IEEE 802 concurrence"
> > > >-Make the same change in Slide 12.
> > > >
> > > >On Slide 18, change "Assuming 802 becomes the authority for all
>changes
> > > >to 8802-x standards" to "Assuming 802 has approval authority for
>all
> > > >changes to 8802-x standards"
> > > >
> > > >(4) [Technical, not required] The process described on Slide 16 is,
>in
> > > >my view, awkward, redundant and impractical. I don't understand why
> > > >ISO/IEC should have to run one ballot to endorse the 802 standard
>and a
> > > >second ballot to adopt it as an 8802 standard. If we think the
>second
> > > >step is required, then we must think that the endorsement process
> > > >doesn't satisfy the needs. So why bother with in at all? It's a lot
>of
> > > >trouble, and it would force a long delay before adoption.
> > > >
> > > >Remedy: I am not proposing a remedy at this time, because I think
>that
> > > >802 is too far along with its decision-making process to
>reconsider. If
> > > >it were earlier in the process, I would suggest that propose to
>endorse
> > > >either the endorsement process or the adoption process, but not
>both.
> > > >Personally, I'd prefer a modified version of endorsement.
> > > >
> > > >(5) [Editorial] Slide 4 says "SC6 has started a review of the
>8802-1
> > > >cooperation agreement". This is not the whole story. 6N13127 is
>seeking
> > > >comments three items:
> > > >1. 6N11917: Procedures for ISO/IEC JTC1 SC6 WG1 and IEEE 802 LMSC
> > > >Cooperative Working 2. TR 8802-1:2001 3. All relevant resolutions
> > > >
> > > >Remedy:
> > > >-Change "SC6 has started a review of the 8802-1 cooperation
>agreement"
> > > >to "SC6, via 6N13127, is seeking comments on the method of
>cooperation
> > > >between SC6/WG1 and IEEE 802."
> > > >-Likewise: Change title of Slide 8 from "SC6 has started a review
>to
> > > >resolve the problems with the 8802-1 cooperation agreement" to "SC6
>has
> > > >started a review to resolve the problems with the 802 cooperation".
> > > >
> > > >(6) [Technical] My Comment 5 is related to a broader problem that
>is a
> > > >bit harder to solve. Our document revolves around suggestions to
>change
> > > >8802-1 so as to improve the process. But the request for comments
> > > >doesn't force us to consider 8802-1 as the only venue for the
>process.
> > I
> > > >believe that 8802-1 is the wrong venue to describe the process. In
>my
> > > >view, 8802-1 was, from the start, an inappropriate place to define
> > > >procedures. It's a Technical Report, not a procedural agreement
>between
> > > >IEEE and ISO/IEC. There is no way, procedurally, to turn 8802-1
>into a
> > > >true agreement. There is, for instance, no place for IEEE to sign
>it.
> > > >
> > > >Remedy: I think it is too late to suggest an alternative type of
> > > >document to contain the process. However, we can at least stop
> > insisting
> > > >that 8802-1 be the right venue. If we make the following changes,
>we
> > > >will still be specifying the kind of process we want, but we won't
> > > >saying that process needs to be defined in 8802-1:
> > > >
> > > >-On Slide 11, change "8802-1" to "Process" in the title -On Slide
>12,
> > > >change "8802-1 should..." to "Process should..."
> > > >-On Slide 13, change "8802-1" to "Process" in the title -On Slide
>13,
> > > >change "This requires 8802-1 to specify" to "This requires process
>to
> > > >specify"
> > > >-On Slide 14, change "8802-1" to "Process" in the title and in both
> > > >places in the Proposed resolution column -On Slide 15, change
>"8802-1"
> > > >to "Process" in the title -On Slide 16, change "8802-1" to
>"Process" in
> > > >the title -On Slide 16, change "modified process for 8802-1" to
> > > >"modified process"
> > > >-On Slide 17, change "8802-1" to "Process" in the title and in both
> > > >places in the Proposed resolution column -On Slide 18, change
>"8802-1"
> > > >to "Process" in the title and in the Proposed resolution column -On
> > > >Slide 19, change "8802-1" to "Process" in the title -On Slide 20,
> > change
> > > >"8802-1" to "Process" in the title and in the Proposed resolution
> > column
> > > >
> > > >(7) [Technical] Slide 21 says "8802-1 should not contain any
>technical
> > > >material". Likewise, Slide 12 says 8802-1 should "Not contain any
> > > >technical material." It's true that 8802-1 has both technical and
> > > >procedural content, and that's not good. But this proposal would
>remove
> > > >the wrong part. It really doesn't make any sense for us to
>recommend
> > > >that ISO/IEC maintain a "Technical Report"
> > > >and insist that it be without technical content.
> > > >
> > > >Remedy:
> > > >-On Slide 12, delete "Not contain any technical material"
> > > >-Delete Slide 21.
> > > >
> > > >Roger
> > > >
> > > >
> > > >On Sep 21, 2006, at 02:34 PM, Paul Nikolich wrote:
> > > >
> > > > > Dear EC,
> > > > >
> > > > > The tentative result on version 10 is shown below. If you have
>not
> > > > > explicitly cast a vote on version 10, please cast your vote as
>soon
> > as
> > > > > possible, as we need to submit the recommendation to SC6
>shortly.
> > > > >
> > > > > Regards,
> > > > > --Paul
> > > > >
> > > > > Vote categories: APP DIS ABS DNV
> > > > > --------------------------------------------------
> > > > > VC Mat Sherman APPv10
> > > > > VC Pat Thaler APPv10
> > > > > ES Buzz Rigsbee APPv10
> > > > > RS Bob O'Hara DNVv10
> > > > > TR John Hawkins APPv10
> > > > > 01 Tony Jeffree APPv10
> > > > > 03 Bob Grow APPv10
> > > > > 11 Stuart Kerry APPv10
> > > > > 15 Bob Heile DNVv10
> > > > > 16 Roger Marks DNVv10
> > > > > 17 Mike Takefman APPv10
> > > > > 18 Mike Lynch APPv10
> > > > > 19 Steve Shellhammer APPv10
> > > > > 21 Vivek Gupta APPv10
> > > > > 22 Carl Stevenson APPv10
> > > > > ME Geoff Thompson does not have a vote, endorses v10
> > > > > ---------------------------------------------------
> > > > > 15 TOTALS 12 0 0 03
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Paul Nikolich"
> > > > > To:
> > > > > Sent: Tuesday, September 19, 2006 7:23 PM
> > > > > Subject: [802SEC] +++EC Email ballot (closes no later than
> > > > > 25SEP2006)+++ Motion to approve the attached EC SC6
>recommendation
> > > > >
> > > > >
> > > > >> Dear EC Members,
> > > > >>
> > > > >> A revised version of the IEEE 802 recommendation on the 8802-1
>and
> > > > >> related documents requested by SC6 is attached for EC approval.
> > > > >>
> > > > >> Motion: The 802 LMSC EC resolves to adopt the attached SC6
> > > > >> recommendation version 07 dated 19SEP06 (appropriately edited
>to
> > > > >> remove the "DRAFT" and "Change History" text.)
> > > > >>
> > > > >> Moved-Tony Jeffree Seconded-Mat Sherman
> > > > >>
> > > > >> Please cast your vote as soon as possible. The ballot closes
>the
> > > > >> earlier of either 25 Sept 2006 or 24 hours after every EC
>member
> > has
> > > > >> cast a vote.
> > > > >>
> > > > >> Regards,
> > > > >>
> > > > >> --Paul Nikolich
> > > > >>
> > > > >> ----------
> > > > >> This email is sent from the 802 Executive Committee email
>reflector.
> > > > >> This list is maintained by Listserv.
> > > > >>
> > > > >
> > > > > ----------
> > > > > This email is sent from the 802 Executive Committee email
>reflector.
> > > > > This list is maintained by Listserv.
> > > > >
> > > > > ----------
> > > > > This email is sent from the 802 Executive Committee email
>reflector.
> > > > > This list is maintained by Listserv.
> > > > >
> > > > > ----------
> > > > > This email is sent from the 802 Executive Committee email
>reflector.
> > > > > This list is maintained by Listserv.
> > > > >
> > > > >
> > > >
> > > >----------
> > > >This email is sent from the 802 E
> > > >
> > > >
> > > >----------
> > > >This email is sent from the 802 Executive Committee email
>reflector.
> > This
> > > >list is maintained by Listserv.
> > >
> > > ----------
> > > This email is sent from the 802 Executive Committee email reflector.
> > This list
> > > is maintained by Listserv.
> >
> > ----------
> > This email is sent from the 802 Executive Committee email reflector.
>This
> > list is maintained by Listserv.
>
>----------
>This email is sent from the 802 Executive Committee email reflector. This
>list is maintained by Listserv.
Bob Heile, Ph.D
Chairman, ZigBee Alliance
Chair, IEEE 802.15 Working Group on Wireless Personal Area Networks
11 Louis Road
Attleboro, MA 02703 USA
Mobile: +1-781-929-4832
email: bheile@ieee.org
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.