Alan,
Nowhere does it say that there needs to be a "formal decision." If the existing Bylaws required a vote, or even a "formal decision," before entering into the "mutually acceptable solution" process, the Bylaws would say so. Instead, a more flexible term was chosen -- "determines to take an action." Assuming competent lawyers, these language choices are meaningful and deliberate. Elsewhere, the Bylaws clearly state when there are votes required (some variation of the word "vote" is used ~200 times in the ICANN Bylaws). "Determines to take an action" is a unique phrase within the bylaws and virtually unique outside of it -- indeed, all but one Google result when searching on that term is a reference to this particular Bylaw. It's fairly clear to me that something less formal than a vote was intended by choosing this unique phrase.
It's my understanding that this distinction is carried out in the Board's actual practices, which have utilized the flexibility offered by this language. As presently drafted, the Board is able to identify a situation where it appears that they are going to take an action that would be inconsistent with GAC Advice; at that point, they would approach the GAC, tell them why and enter into the "mutually acceptable solution" process -- without requiring a formal vote of the Board. This gives the Board more flexibility and leeway to work with the GAC, and it's my understanding that the Board has in fact worked in this manner. The CCWG proposal would take away that flexibility and mandate a formal vote of the Board, requiring the Board to take an adversarial stance with the GAC. [Choosng to use the flatly negative word "reject" instead of the more nuanced phrase "take an action that is not consistent with" is just the icing on the cake.]
There is another issue raised by this new language. With this revision, it is far from clear what the status of GAC Advice that not been rejected by a 2/3 vote? If the Board takes a vote, but the rejection fails to pass, is the GAC Advice now "accepted" (possibly by a vote of 1/3+1) and binding on ICANN? What about GAC Advice on which no vote has been taken -- is that Advice "accepted" and binding on ICANN and, if so, when? [Compare this to the Community's right to reject a standard bylaws change -- if the community does not elect to do so, or attempts to do so and fails, that bylaw clearly become binding upon ICANN.]
The combination of a 2/3 threshold and a mandatory vote to reject GAC Advice creates a presumption that GAC advice will be accepted. This presumption is novel and clearly elevates GAC Advice to a new level of deference within the ICANN process.
Although none of this is explicitly stated in the detailed explanation in Annex 11, the more I consider this and the more people I talk to, the more convinced I am that what I've laid out above is exactly what was intended by some of those involved in the drafting process for the Bylaw revision, and the rest of us just didn't see it at the time. Since it's not brought out in the CCWG's explanation, this fundamental change can "fly under the radar" until the Proposal is approved.
I don't believe that this was the intention of the CCWG. If it's not the intention of the CCWG, then my alternative wording would remove this concern. If this is in fact the intention of the CCWG then I think it needs to be part of the explanation set forth in the proposal, so that the intent and effect are clear, and any reader can clearly understand what we have wrought.
Finally, I have to say that this is not an "implementation level" concern. This is, if you will, a "policy level" concern. If this gets baked into the accepted proposal, then the implementers will essentially be bound to carry this out in the implementation (i.e., the drafting of the "real" Bylaw language). Any later attempt to change a concept stated in the accepted and transmitted final proposal will face a very high set of hurdles, at best. Now is the time to deal with this.
Greg