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.