There were widespread reports of irregularities in the BRM held in Geneva. At the meeting held on 13th March 2008, the Indian delegation to the BRM gave a debriefing to members of LITD15, which is reviewing OOXML. The very diplomatic Deputy Director General of BIS said that he had not attended such a meeting in 28 years of his career. Based on the debriefing, the LITD15 committee sent a message to ISO with India's suggestions (we are too polite to call it a protest!) on how the BRM should be conducted. Before sending off these comments, everyone was asked if they have any objections and since no one (including Microsoft) had any objections, these comments were unanimously approved.
LITD15's comments to ISO are given below along with my comments.
1. All technical issues raised by different member bodies should be discussed adequately during BRM. If balloting on technical issues is envisaged, it should not be done during BRM. Balloting may be done after discussion within corresponding mirror committees of the national bodies providing sufficient time for discussions. In other words, duration of BRM should be in consonance with the requirement of time to sufficiently discuss all technical issues raised.
MY COMMENT: The biggest complaint about the BRM was that five days is too little time to review the changes. The five day BRM was sufficient only to discuss 54 issues and the rest of the issues were decided over a paper ballot. The Indian delegation pointed out that if a paper ballot is to be done, why should countries go to the expense of sending four people to Geneva for five days? It would be much simpler to do a ballot from the home country after discussion with committee members.
2. If the basic structure of the submitted document is proposed to be changed during BRM, provision for circulation of restructured integrated document for consideration of member bodies should be incorporated in the Fast Track Process as well. Enough time should be given to member bodies to examine/carry out the impact assessment of the modifications proposed.
MY COMMENT: The scope of the document has changed. The document is being split into five parts. If the scope and nature of the document changes substantially (as it has in this case) then adequate time needs to be given to review the changed proposal. As one of the esteemed academic members of LITD15 says, "What document is there for us to vote upon?"
3. Definitions of newly introduced terminologies should be clearly articulated before discussions are initiated on the related issues.
MY COMMENTS: The fact that we have to make such an elementary request highlights the hollowness of the "Fast-track" process and the BRM.
4. Voting process especially in terms of considering simple majority/two-third majority and counting of P member/O Member votes at BRM should strictly be adhered to as defined in JTC 1 Directives.
MY COMMENTS: This is a serious ethical and governance issue. If O member votes are not counted (as per JTC 1 directives) then the Microsoft claim of getting "more than 98 percent of the comments were accepted" falls flat. The voting was forced upon the BRM after overruling the objections of several countries, including India. The vote was to be decided by a simple majority by paper ballot for 847 issues which could not be discussed. Four P members (Czech Republic, Finland, Norway and Poland) voted for approving the 847 issues, Four P members (including India, Malaysia, South Africa and the US) voted against these issues. The votes of two O members (Chile and Ivory Coast) was improperly counted in contravention of JTC1 rules. The head of the Chile delegation landed in Geneva on the last day, just to vote Yes. The head of the Ivory Coast delegation is Wemba Opota, a Senegalese citizen, who is responsible for Microsoft West Africa!
Even by the "simple majority" rule imposed by the ISO conveners on the BRM, the result is a TIE and not a majority, as claimed by Microsoft.
5. It is suggested that the resolution to the issues raised during the process of development of standard shall be provided before the publication of the standard and shall be included in the published standard and shall not be deferred to the maintenance phase.
MY COMMENTS: As the delegation said, maintenance is for issues that are identified *after* the standard has been frozen. Known issues cannot be swept under the carpet under the guise of "maintenance."