[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.