From: IAB, IESG Purpose: In response to Liaison Statement from ITU-T Study Group 11, August, 2010 For action to: ITU-T Study Group 11 For information to: TSAG Submission Date: 01/12/2010 Contact: Patrik Faltstrom Monique Morrow Thank you for your liaison regarding work in Q5/SG11 on the Q.flowstatesig draft Recommendation, posted August, 2010. We appreciate the update on your work and your desire to continue close collaboration and engagement, for example as specified through the RFC 4775 process. We thank Dr. Roberts for publishing draft-roberts-fsasignaling, which encourages the IETF to review and comment on the FSA signaling protocol and the relationship among that work, the Q5/SG11 Q.flowstatesig draft recommendation, and the IETF Internet protocols. We have examined this proposal and its predecessors, and conclude that they are on the boundary between extensions to IETF protocols such as TCP and UDP, and a completely independent protocol stack. We are not able to deduce reliably the intentions of the proponents in this regard. That uncertainty makes the correct application of the principles of RFC 4775 about where work on this proposal should be done unclear. We believe that it has become important that the intent of the proposal be clarified. If the conclusion of Q5/SG11 is that the intent is to extend or interwork with IETF protocols, then the work should be transferred from ITU-T to the IETF as implied in RFC 4775 and agreed on between ITU-T and IETF under the general principle that work extending a protocol that was developed in one body should be done in that same body. If this is the way forward, please contact the IETF Liaison Manager for the ITU, Patrik Faltstrom , to initiate such a transfer. If, on the other hand, the proponents conclude that a separate protocol is intended, then the ITU-T should insist that the specification follow well-established principles for co-existence of different protocols in the same environment. Those principles ensure technical independence and avoiding confusion in the marketplace. In particular, different identifiers, formats, protocol names, and protocol component names be used at all levels of the protocol stack implied by the design. To do otherwise creates significant, and unnecessary, risk that the protocol could easily, even if accidentally, become a threat to the stable and predictable operation of the public Internet if it leaks out of its intended isolated environment. The Internet technical and operational communities have long and sometimes painful experience with such leaks occurring as presumed network boundaries shift and evolve, border equipment does not perform exactly as expected, and so on. We look forward to a response that provides a clarification about the intention for this proposal, allowing all of us to move toward agreement on the treatment of FSA signaling specification and progress toward the development and publication of the specification.