Liaison statement
Lessons learned about cooperation between SDOs

Submission date 2009-07-09
From IETF (Patrik Fältström)
To ITU-T (Reinhard Scholl)
Response contact
Purpose For information
Attachments IETF Contribution to GSC14
Source:	IETF
Title:	Lessons learned about cooperation between SDOs
Agenda Item:	PLEN 10 (refers to 6.10)
Document for:	Information


The IETF would like to inform the participating organizations at GSC-14
about what our experience has been regarding ongoing cooperation
between Standard Development Organizations (SDOs).


Appendix A of ITU-T Recommendation A.5 that is also made available as
RFC2436 (


Based on our experience, we feel that that a small number of
recommended actions can make cooperation easier, specifically when
there are topics that are discussed in multiple SDOs 
Over the years, we have seen that cooperation is needed not only when
an SDO is taking on a new work item, but also over time as the work
item progresses. This because the boundary on what one SDO is working
on might become fuzzy, and at some point a previously clear cut
differentiation between two SDOs areas of responsibility might not be
as clear anymore.

We have found the following procedures can help avoid conflict:

1.	An SDO should announce “new work” before it decides to take it on,
so other SDOs have time to send liaison statements with ideas on how
the work item should be formed

2.	An SDO should listen for “new work” announcements, and quickly react
if there is a reason for suggestions on how a work item should be

3.	SDOs should minimize potential duplicate work, and minimize this via
collaboration -- not competition, for example by referencing work
produced by other SDOs rather than creating a competing technology

4.	If an SDO feels that changes may be needed in technology defined by
another SDO to make the technology support needed functionality the SDO
should communicate the requirements that they feel the technology
should meet to the other SDO rather than to modify the technology on
their own

5.	Agreements should be created on how to reference work items of other
SDOs, including any related parameter and namespace registries

6.	Ownership of identifiers, namespaces the processes for how they are
defined and changed should be recognized, to minimize confusion on the
meaning of a specific identifier

7.	SDOs should collaborate in such a way that “SDO shopping” is not a
successful tactic, instead SDOs should in a collaborative manner
suggest where the proposed work item is to be discussed

8.	Communication between SDOs should as much as possible be in the form
of ongoing collaboration and, potentially, shared proactive workshops,
since the experts in one SDO might not be aware of the fact a topic may
be very sensitive to some other SDO. Such communication will minimize
more formal objections late in the standards development process

9.	Specifically, if an SDO is making use of another SDO's work, even in
what seems (to their experts) to be simple and harmless manner,
notification to the SDO which developed the technology should be made
as early as possible, so any potential misunderstandings can be caught
as early as possible
We specifically would like to draw the attention to Appendix A of ITU-T
Recommendation A.5 that is also made available as RFC2436.

About the IETF

The Internet Engineering Task Force (IETF) is a large open
international community of network designers, operators, vendors, and
researchers concerned with the evolution of the Internet architecture
and the smooth operation of the Internet. It is open to any interested
individual. The IETF is an organized activity of the Internet Society.

About the Internet Society

The Internet Society is a non-profit organization founded in 1992 to
provide leadership in Internet related standards, education, and
policy. With offices in Washington, DC, and Geneva, Switzerland, it is
dedicated to ensuring the open development, evolution, and use of the
Internet for the benefit of people throughout the world.