Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802SEC] Fwd: P802.16g Disapproval Notification



Roger-

I think we are in violent agreement here. I wrote my note to you on the SEC 
reflector to encourage all WG Chairs and even Task Group/Force chairs to 
spend a little time in RevCom before it is their turn in the spotlight.

I was, and continue to be a strong voice against the compulsory use of 
myBallot. I didn't think it was good enough to be mandatory when the SA 
made that decision and, true to form, they cut way back on the improvement 
work after the cutover date. It is only now that they are signing up for 
significant work to improve it.

My opinion was and is that it is far more effective to put a system like 
his into place by pull rather than push. The object should be to make the 
system sufficiently attractive that people will want to use it  rather than 
forcing them to use it. I use an ATM because it is more convenient using a 
teller window. The same principle should apply (as it has for the automated 
comment handling systems that both you and I have worked on).

In the meantime, its use is required. Bob, David and I keep pushing for its 
improvement. Our views do (recently) seem to be gaining a little more 
traction with the other members of RevCom so my hope have lifted somewhat 
in recent days.

For members of the EC who are about to submit an approval package, I urge 
you to have an 802 member of RevCom take a look at your package before you 
push the "Submit" button. We have to review the package anyway.

Best regards,

Geoff Thompson


At 01:42 AM 6/10/2007 , Roger B. Marks wrote:
>Geoff,
>
>Like you, I believe that it is my responsibility as WG Chair to know
>what RevCom wants and supply it to them. I aim to be meticulous.
>Obviously, in this case, I missed the mark. I did not realize the
>degree to which the RevCom perspective has changed since myBallot
>came along.
>
>But I'm not barking here. I'm simply offering up my story to help
>others become more aware of the risks. After all, not all 802 WG
>chairs are intimately familiar with RevCom, and I think some
>effective communication can help bring more of us toward your state (d).
>
>I am still worried that, due to the nature of myBallot, P802.16g will
>stay stuck in a Catch 22. But that's an issue I plan to take up off- line 
>with my RevCom mentor.
>
>Roger
>
>
>On Jun 9, 2007, at 05:48 PM, Geoff Thompson wrote:
>
>>Roger-
>>
>>I think you are barking up the wrong tree.
>>
>>I would encourage you to task the custodial committee (be it WG, TG
>>or BRC) with doing whatever it takes to assist in creating a RevCom
>>submittal package that is as slippery as possible.
>>
>>Since that group presumably has a strong vested interest in getting
>>the standard approved, my experience is that they will be willing
>>to do whatever it takes to get the job done. If that means re- entering 
>>comments to get them into the system then they'll do it
>>(not without complaint, of course).
>>
>>The job of the WG Chair is to know the system well enough to be
>>able to tell them what to do.
>>
>>There are several approaches available for RevCom submittal
>>packages. I have seen them all tried.
>>
>>         a) The submittal package can have what the submitter thinks
>>should do the job
>>
>>         b) The submittal package can have the minimum that it says
>>it has to have by the rules
>>
>>         c) The submittal package can have b) plus supplementary
>>material in order to provide answers in advance to any anticipated
>>questions.
>>
>>         d) The submittal package can be further tuned on beyond c)
>>by familiarity with the RevCom review process and with the
>>discussions and kind of issues that come up at RevCom. It is
>>difficult to achieve d) without either serving on RevCom or at
>>least spending some time (e.g. 1 meeting/year) in the peanut
>>gallery at RevCom.
>>
>>My experience is that the d) approach is bulletproof.
>>
>>After some ugly experiences a long time ago, I figured out that it
>>was my job to submittal packages through RevCom as smoothly and as
>>quickly as possible. If I had any issues with RevCom processes, it
>>was a bad idea to raise those issues with any submittal package of
>>mine. Better to attack those issues via another path, be it through
>>someone else's submittal package or via ProCom.
>>
>>I hope this helps.
>>
>>Geoff
>>
>>At 12:42 AM 6/9/2007 , Roger B. Marks wrote:
>>>Tony,
>>>
>>>Thanks for taking a look at the details. I appreciate another
>>>perspective.
>>>
>>>I don't agree that failure to discourage amounts to encouraging. I
>>>don't control the voters. Obviously, I'll make a stronger effort in
>>>the future to encourage people to use myBallot. But the only way I
>>>can see to definitively make that work is to simply say that I'll
>>>refuse to accept comments otherwise. I have been always been under
>>>the impression (based on my reading of the IEEE-SA rules, and on what
>>>I have learned from experienced people over the years) that I don't
>>>have the right to do that. Am I wrong?
>>>
>>>I could say the following: "You are strongly encouraged to submit
>>>through myBallot; otherwise, we will still accept your comments, but
>>>approval of the resulting ballot may be jeopardized." This may
>>>motivate some people. Others may ignore the advice simply because
>>>they are accustomed to comment tools that are much more effective and
>>>convenient than myBallot. But the major problem is with Disapprove
>>>voters. If they are really opposed to progression of the draft, then
>>>this position provides them an incentive to bypass myBallot and
>>>thereby block progress at RevCom. In other words, I can't count on
>>>Disapprove voters to follow my words of encouragement.
>>>
>>>I've used the myBallot process only a few times, far fewer than you
>>>have. I believe that the method by which I addressed the back-door
>>>comments was basically equivalent to what we did in the pre-myBallot
>>>days. I think that was a transparent process. But I recognize now
>>>that RevCom has gotten used to the myBallot way of doing things and
>>>now has adjusted to a different view.
>>>
>>>We'll adjust too. But I still feel caught in procedural ambiguity. I
>>>understand that the Operations Manual says "the Sponsor shall make a
>>>reasonable attempt to resolve all comments." To my knowledge, it
>>>doesn't say anything about dismissing non-myBallot comments. But I
>>>think that perhaps this is what RevCom is telling me I have to do.
>>>This is why I say that I feel either direction is risky.
>>>
>>>Roger
>>>
>>>
>>>On Jun 9, 2007, at 12:53 AM, Tony Jeffree wrote:
>>>
>>>>Roger -
>>>>
>>>>What I find somewhat mystifying is why you chose to allow these
>>>>voters to submit comments directly rather than via MyBallot. I hear
>>>>your words about not having encouraged the practice, but failure to
>>>>discourage it comes to the same thing as encouraging it.
>>>>
>>>>It isn't uncommon to have to enter a small number of comments
>>>>received after the ballot has closed (when MyBallot is no longer
>>>>available for use by the ballot group), but when that is necessary,
>>>>the "rogue comment" mechanism can be used by you (or your designee)
>>>>to add such comments to the comment database, thus making the
>>>>process as transparent as possible, both in the eyes of RevCom and
>>>>the balloters. However, at least in my experience, it is unusual to
>>>>have to handle more than a handful of comments that way.
>>>>
>>>>Having read the RevCom comments, particularly the ones that
>>>>indicate they were having difficulty understanding exactly what was
>>>>being presented to them, I am not at all surprised that they
>>>>bounced the submission.
>>>>
>>>>Regards,
>>>>Tony
>>>>
>>>>At 06:17 09/06/2007, Roger B. Marks wrote:
>>>>>To: 802.16 Reflector
>>>>>cc: 802 EC Reflector
>>>>>
>>>>>I have unfortunate news to report on P802.16g.
>>>>>
>>>>>On 26 April, after three Sponsor Ballot recirculations and a 99%
>>>>>approval ratio (136 Approve, 2 Disapprove), I submitted P802.16g/D9
>>>>>to RevCom:
>>>>>  <http://ieee802.org/16/docs/07/80216-07_028.pdf>
>>>>>Yesterday, the approval request was rejected by the IEEE-SA
>>>>>Standards
>>>>>Board, upon RevCom's advice.
>>>>>
>>>>>To the best of my understanding, the core reason for the rejection
>>>>>was that some of voters submitted comments directly to the Working
>>>>>Group instead of using the IEEE-SA's myBallot system. This was
>>>>>partly
>>>>>related to the unresolved comments of the two disapprove voters:
>>>>>  <http://ieee802.org/16/docs/07/80216-07_027.pdf>.
>>>>>
>>>>>This issue was raised by several RevCom members prior to the
>>>>>meeting.
>>>>>Phillip Barber (the Task Group Chair) and I prepared responses to
>>>>>those comments for RevCom consideration, arguing that the WG did
>>>>>follow documented procedures and, because it was required to
>>>>>address
>>>>>all comments, had little choice in how to proceed:
>>>>>  <http://ieee802.org/16/docs/07/80216-07_032.pdf>.
>>>>>I participated by telephone in the RevCom meeting of 6 June to
>>>>>discuss these issues but was unable to reverse the opinion.
>>>>>
>>>>>[I would like to add that the RevCom administrator responded to the
>>>>>research in our response by indicating that 802.16-07/012r4
>>>>>seems to
>>>>>have not been included in the second recirculation; if so, it was
>>>>>likely due to an accidental omission on my part, for which I assume
>>>>>responsibility. However, RevCom at no time raised this issue in its
>>>>>deliberations, so it does not appear to have directly affected the
>>>>>decision.]
>>>>>
>>>>>During the RevCom meeting, I requested advice as to what kind of
>>>>>approach we could follow to assure that we satisfy RevCom's
>>>>>concerns.
>>>>>When no clear answer arose, I requested assignment of a RevCom
>>>>>"mentor" to provide feedback and assurance that our future steps
>>>>>will
>>>>>be satisfactory. Geoff Thompson volunteered.
>>>>>
>>>>>The formal notice of disapproval is below, and at:
>>>>>  <http://ieee802.org/16/docs/07/80216-07_033.pdf>.
>>>>>I am pleased to see that it provides some explicit directions on
>>>>>how
>>>>>we can proceed: "The Sponsor must conduct a recirculation ballot to
>>>>>show all unresolved comments associated with negative votes, and
>>>>>their responses, to the ballot group. The Sponsor is encouraged to
>>>>>input all comments and responses into the myBallot system for
>>>>>ease of
>>>>>submittal package review by RevCom. The Sponsor shall inform the
>>>>>ballot group that the myBallot system must be used as the mechanism
>>>>>for ballot comment submission."
>>>>>
>>>>>The middle sentence may be the most challenging. Based on my
>>>>>understanding of the software, I am not currently aware of any
>>>>>way to
>>>>>input comments and responses into the myBallot system prior to a
>>>>>recirc. I have inquired with IEEE-SA staff as to whether they can
>>>>>arrange a way to do so.
>>>>>
>>>>>RevCom does not hold conference call meetings during the summer, so
>>>>>the next chance for RevCom review of this draft is 26 September.
>>>>>This
>>>>>delay will cause pain to the interesting parties. Since the base
>>>>>standard will by then be more than three years old, it appears that
>>>>>we may need to address the rule prohibiting amendments after three
>>>>>years. There are some exceptions to the rule, but I don't fully
>>>>>understand the language in the IEEE-SA Standards Board Operations
>>>>>Manual, so further research will be required.
>>>>>
>>>>>I'm copying the IEEE 802 EC so that other Working Groups will be
>>>>>aware of this problem. Working Groups receiving comments outside
>>>>>the
>>>>>myBallot system will need to decide whether to address those
>>>>>comments
>>>>>or to ignore them. I am concerned that they will face risk either
>>>>>way. In any case, it would certainly be wise to make an effort, in
>>>>>your Sponsor Ballot cover letters, to steer your voters toward the
>>>>>use of myBallot.
>>>>>
>>>>>Regards,
>>>>>
>>>>>Roger
>>>>>
>>>>>Roger B. Marks  <r.b.marks@ieee.org>
>>>>>NextWave Broadband Inc.
>>>>>Chair, IEEE 802.16 Working Group on Broadband Wireless Access
>>>>><http:// WirelessMAN.org>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Begin forwarded message:
>>>>>
>>>>>>From: d.ringle@ieee.org
>>>>>>Date: June 8, 2007 09:59:57 AM MDT
>>>>>>To: r.b.marks@ieee.org
>>>>>>Subject: P802.16g Disapproval Notification
>>>>>>
>>>>>>
>>>>>>8 June 2007
>>>>>>
>>>>>>Roger Marks
>>>>>>NextWave Broadband, Inc.
>>>>>>4040 Montview Blvd
>>>>>>Denver, CO  80207
>>>>>>
>>>>>>cc:   Paul Nikolich, C/LM Liaison
>>>>>>          Richard Snyder, MTT Liaison
>>>>>>          Michael Kipness, Program Manager
>>>>>>          William Ash, Program Manager
>>>>>>          Kim Breitfelder, Manager-Standards Editing and Production
>>>>>>          Geoff Thompson, RevCom mentor
>>>>>>
>>>>>>RE: NEW P802.16g/D9 (C/LM + MTT) IEEE Standard for Local and
>>>>>>Metropolitan
>>>>>>Area Networks - Part 16: Air Interface for Fixed and Mobile
>>>>>>Broadband
>>>>>>Wireless Access Systems - Amendment 3: Management Plane
>>>>>>Procedures and
>>>>>>Services
>>>>>>
>>>>>>Dear Roger,
>>>>>>
>>>>>>I must inform you that P802.16g was disapproved as a new amendment
>>>>>>to IEEE
>>>>>>Std 802.16-2004 by the IEEE-SA Standards Board on 7 June 2007.
>>>>>>
>>>>>>The Sponsor must conduct a recirculation ballot to show all
>>>>>>unresolved
>>>>>>comments associated with negative votes, and their responses, to
>>>>>>the ballot
>>>>>>group. The Sponsor is encouraged to input all comments and
>>>>>>responses into
>>>>>>the myBallot system for ease of submittal package review by
>>>>>>RevCom.
>>>>>>The
>>>>>>Sponsor shall inform the ballot group that the myBallot system
>>>>>>must
>>>>>>be used
>>>>>>as the mechanism for ballot comment submission. Geoff Thompson
>>>>>>will
>>>>>>be the
>>>>>>RevCom mentor to the Sponsor.
>>>>>>
>>>>>>Sincerely,
>>>>>>****************************************************************
>>>>>>David L. Ringle
>>>>>>Manager - IEEE-SA Governance, Policy & Procedures
>>>>>>IEEE Standards Activities Department
>>>>>>445 Hoes Lane
>>>>>>Piscataway, NJ  08854
>>>>>>TEL: +1 732 562 3806
>>>>>>FAX: +1 732 875 0524
>>>>>>d.ringle@ieee.org
>>>>>>****************************************************************
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>----------
>>>>>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.