In Defense Of Cooperation

[Callaghan, Robert]

Tom,

I have to agree that the H.248/Megaco project, in the end, is a success.
And much of the success is the process and cultural knowledge that was
gained.  Yes, at this point, everyone is suffering some pain.  However, very
little greatness is gained without pain.

The group culture and dynamic is very different between the ITU-T and the
IETF.  It is hard for anyone to gain trust in a partner, when you do not
know or understand what the partner is doing.  If you don't understand what
a partner is doing, can you trust that you understand what he is thinking?
(YES; but with time and effort!)

Again, I think that an important success of this work is that it succeeded.
However, we need to understand, as much as possible, as to why and how it
succeeded.  This is why I asked you (Tom) to do a post project debriefing
paper.  It will help little if this only details corrections to errors.  To
be useful, it must detail the successes, including all the little successes.
>From this information it will be possible to determine how to do a
cooperation project again.  Without this information, most people will be
afraid to try a cooperation project in the fear that it will just as painful
as second time.

An important part of the success is the core group of people who
participated in all the IETF and the ITU-T activities.  I doubt this this
will be typical of any future work.  So the question will remain how to
share work between the normal ITU-T process involving contributions at
meetings and the IETF process involving, to a greater extent, work shared
over a mailing list.  Both processes are valid, but their dynamics are very
different.  (The two groups cannot even agree on a document format that can
be shared between the two groups.)

There have been many intemperate statements made by too many people
regarding IETF and ITU-T.  This is not limited to the H.248/Megaco project.
These statements will not help progress; but in many cases represent the
fears of the individual groups.  IETF and ITU-T originated in very different
environments.  The future shock is these environments are becoming one.
Neither group has the totality of knowledge.  Both groups have a valid pool
of knowledge that adds to the whole and from which all can learn.  But how
to bring this sharing about?  The H.248/Megaco project was a start.  Let us
find away to continue.

Robert Callaghan

------------------------------------------------------------------
Robert Callaghan
Siemens Information and Communication Networks
Tel: +1.561.997.3756    Fax: +1.561.997.3403
Email:  Robert.Callaghan at ICN.Siemens.com
------------------------------------------------------------------

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor at NORTELNETWORKS.COM]
Sent: Sunday, February 27, 2000 7:43 PM
To: ITU-SG16 at mailbag.cps.intel.com
Subject: In Defense Of Cooperation



Paul Jones used the term "H.248/Megaco fiasco", and Dale Skran was quite
intemperate in his criticism of the joint effort when he spoke in Geneva.  I
was not in a position to raise much of a defense there, because it would
have conflicted with Glen's positioning of the H.248 work as stable.  Now
that that issue is water under the bridge, I would like to suggest that it
really has been quite a successful project.  I don't think we should go at
it in quite the same way in the future, but we should not come away totally
discouraged about the prospects for IETF/ITU-T cooperation.

Here are bases for my conclusion:

We have been technically successful, and what we have created is better than
it would have been if created in either body separately.  To be specific, we
retained a great deal of the thinking and experience which went into MGCP,
but escaped the limitations MGCP's connection model imposed on the use of
different bearer types and multiple media.

There is a perception that the IETF decision model is lacking because so
much had to be done at the ITU-T meetings.  However, the grueling effort put
in at the latter resulted partly because of fundamental conflict to which
Q.13-14 has been unaccustomed (Monterey and much of Red Bank in particular)
and partly because there was so much to cover.  This may have given the
impression that the IETF didn't do anything on their watch, but we did work
through a lot of material.  Moreover, both Q. 14/16 and Megaco made a host
of decisions which have shaped the final protocol.

I have pleaded guilty to a failure to complete IETF process in timely
fashion.  There was a brief window of opportunity in early December when it
seemed that the list was quieting down.  If I had made Last Call at that
point, the long list of issues which was contributed into the Geneva meeting
would instead have been forced into the open at an early enough point that
IETF process could still have been completed in time for the Geneva meeting.
I consider this to be a tactical failure, in that real work was done in the
intervening month and a half, and the protocol specification is the better
for it.

We have come to a point where SG 16 is thoroughly mistrustful of the IETF as
a partner, and has shown this distrust by negotiating a contract for further
progress on H.248/Megaco down to the last detail.  The pity is that I could
see that SG 16 was overly anxious to do its part, from Santiago onwards.  We
were not really ready for determination at that point, and we were not ready
for decision coming out of Red Bank.  I can understand that SG 16 feels
betrayed because the IETF was not finished in time, but the fact is that the
job was bigger than the schedule allowed for.

This is why, if I am ever involved in a project like this again, I will
insist that the IETF and ITU-T working together create an IETF Proposed
Standard before determination ever happens.  The opportunity for false
expectations and artificially tight deadlines will thus never arise, and
both sides will be the happier for it.

Tom Taylor
Advisor -- Emerging Carrier IP Standards
E-mail: taylor at nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000228/d633af76/attachment-0001.htm>