Liaison statement
Lessons learned about cooperation between SDOs

State Posted
Posted Date 2009-07-09
From Group IETF
From Contact Patrik Fältström
To Group ITU-T
To Contacts 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 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.