Shouldn't this be considered as BCP rather than Informational? Formal liaison rules don't substitute well for responsibility and judgment. I would suggest that a set of guidelines for collaboration between IETF and other organizations in general should include an analysis of common failure modes, and encourage the participants to exercise good judgment and oversight so that these don't occur. Think of it like a set of "security considerations": analyze the threats and describe how the threats can be mitigated by the form of the liaison relationship. Some examples of common failure modes: *** Someone will misrepresent what's happening in the other group and present their own or their company's point of view as if it were the other group's. This was the example given earlier. The threat is that someone might be given more deference because they are "from the ITU". (Note that this isn't so different from the case where a 'representative' from a Major Software vendor stands up and makes statements like 'my company will never implement X'.) *** Someone will "game" the system, for example, to move forward a technical proposal by telling each group that "the other group wants this". So, for example, everyone in the IETF working group tries to help out the ITU by endorsing a proposal because they think the ITU needs it, while everyone in the ITU goes along with it because they think the IETF has already approved it. Meanwhile, nobody really cares or wants this feature. *** People will "standards shop": They'll choose one organization or another in response to different requirements on intellectual property claims or assertions, or different requirements for security considerations, or independent interoperable implementations. One group or the other winds up considering technologies or specifications that don't meet their criteria. *** Second-guessing: When turned down by one organization because the proposal is disruptive, inconsistent with that organization's architectural or operational principals, individuals who were frustrated will take the standards proposal to another organization which doesn't have the same design principals or requirements. *** Mutual deadlock: each group is waiting for the other to finish a specification, and there is no way to easily more forward with interlinking specifications. *** Misunderstanding of other group's processes: working groups in one organization avoid doing the coordination with the other organization because of misunderstanding, fear, or deliberate sabotage.