Re: [802SEC] +++EC Email ballot (closes no later than 25SEP2006)+++ Motion to approve the attached EC SC6 recommendation+++tentative result on v10
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.