Re: [802SEC] [802SEC] +++EC Email ballot (closes no later than 25SEP2006)+++ Motion to approve the attached EC SC6 recommendation+++tentative result on v10
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
><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" <paul.nikolich@ATT.NET>
> > To: <STDS-802-SEC@listserv.ieee.org>
> > 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.