Subject: Re: Last Call: IETF and ITU-T Collaboration Guidelines to Informational

From: "John Stracke" <[email-masked]>
Date: Sat, 9 Mar 2002 08:53:56 -0500

>However, what's the point of tying someone to the 
>rails after the train wreck?

As a deterrent, I think.  "Don't misrepresent the ITU position, because 
they know whom they sent, and you'll blow your credibility in the ITU."

/=================================================================\
|John Stracke                    |Principal Engineer              |
[email-masked]   |Incentive Systems, Inc.         |
|http://www.incentivesystems.com |My opinions are my own.         |
|=================================================================|
|If jumping off a bridge was "the industry standard", would you do|
|it?                                                              |
\=================================================================/

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 9 Mar 2002 08:27:51 -0700 (MST)

> From: "John Stracke" <[email-masked]>

> they know whom they sent, and you'll blow your credibility in the ITU."

Those who care enough about their credibility to not misrepresent the
ITU position won't misrepresent it whether they are official
representatives or not.  Those who are swayed by other considerations
will, as in that infamous IEEE 802.3 case, be swayed even if they are
official representatives.  Some people are incapable of foreseeing
the possibility that they might be held accountable for what they see
as minor fibs or saying what they think they will be able to convince
the ITU to do expecially if the IETF has gone that way--again, apparently
as in that IEEE 802.3 example.

Vernon Schryver    [email-masked]

---

From: John W Noerenberg II <[email-masked]>
Date: Mon, 11 Mar 2002 16:49:09 -0800

>they know whom they sent, and you'll blow your credibility in the ITU."

The trouble here is the damage has already been done.  Perhaps this 
person would not cause further problems, but the idea of the 
Guidelines draft is to prevent the problem in the first place.

Because we want to find a way to collaborate, the draft should make 
some additional accommodations for differences between the ITU-T and 
the IETF.

It must be made clear in section 3.2.2 someone may put on an ITU 
"hat" for the purpose of reporting on status of some  ITU Working 
Party's work as it relates to the work of the IETF working group. 
However, the ITU hat confers no additional value to comments made by 
that person outside the purpose on reporting the ITU Working Party's 
status.  This is much the same as when a WG chair puts on his WG hat 
to clarify a point of procedure, but must remove it in order to 
comment on the work under discussion.

Section 3.2.1 is problematic, because it assumes that someone 
participating in an IETF Working Group and also participating in an 
ITU-T Working Party is capable of representing the IETF's point of 
view.  Rough consensus implies there is no single IETF point of view 
on an issue.  What is available is what the IETF has published as 
RFCs.  Those are the authoritative statements of the IETF, and 
represent the IETF's rough consensus.

I realize there is a need for collaboration before a document is 
published as an RFC.  However, it is a disservice to both the ITU-T 
and to the IETF to say that an individual can represent the IETF's 
view before an RFC is published. 3.2.2 should make clear that even if 
someone participating in an IETF working group has been designated as 
a delegate to an ITU-T meeting, that individual represents the point 
of view of the IETF only insofar as he is consistent with what is 
published in RFCs.  I-Ds may contain interesting information, but 
they aren't authoritative.

3.3.1 deals with I-Ds, but doesn't discuss I-Ds which aren't under 
the aegis of a IETF working group.  The IETF does not now restrict 
access to I-Ds (or any other document).  The ITU should not need 
permission to consider them.

best,
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, the makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 12 Mar 2002 11:50:50 -0800

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.