Liaison statement
Lessons learned about cooperation between SDOs

Source: IETF
Title:  Lessons learned about cooperation between SDOs
Agenda Item:    PLEN 10 (refers to 6.10)
Document for:   Information

1       PURPOSE

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).

2       REFERENCES

Appendix A of ITU-T Recommendation A.5 that is also made available as RFC2436
(http://www.ietf.org/rfc/rfc2436.txt).

3       CONTENT

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 formed

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.

___________