Subject: Response to "Protocol for the Support of Flow State Aware Transport Technology" Date: Mon, 27 Apr 2009 12:00:22 -0700 (PDT) To: ITU-T SG 11 , ITU-T TSAG From: The IESG CC: Scott Bradner , Monique Morrow , Patrik Faltstrom , Jari Arkko , Ralph Droms , Magnus Westerlund , Lars Eggert , Arshey Odedra , Wei Feng , Kaoru Kenyoshi , Tina Tsou Response Contact: IESG Technical Contact: IESG Purpose: For Action Deadline: July 13, 2009 The IESG thanks ITU-T Study Group 11 for their liaison statement concerning their draft work on ITU-T Recommendation Q.Flowstatesig, "Signalling protocols and procedures relating to flow state aware access QoS control in an NGN". The IESG hopes that the ITU-T and the IETF continue to have a productive cooperation on this topic. As SG11 has noted, some of the work items related to Q.flowstatesig require closer coordination between the two organizations. The IESG would like to emphasize that several such issues have to be resolved before Q.flowstatesig can be published as an ITU-T Recommendation. First, the IESG has determined that there is at least one issue of critical importance for which a mutually agreeable resolution must be reached, before any publication of Q.flowstatesig as an ITU-T Recommendation can take place: The Q.flowstatesig proposal uses a new IPv6 hop-by-hop option. As specified in RFC2780, IANA will only assign an IPv6 option number following IESG Approval, IETF Consensus (now called IETF Review) or an IETF Standards Action. (Please see RFC5226 for details.) For the assignment of IPv6 hop-by-hop options, it is current practice to require IETF Consensus or a Standards Action, due to their potentially problematic impact on the broader Internet architecture. The proponents of Q.flowstatesig will consequently need to publish an Internet Draft describing the protocol mechanisms for which the new IPv6 option is used, and have it undergo the normal IETF consensus process for publication as an RFC. IANA assignment of the requested IPv6 option number will occur after the successful completion of this process. Any prior publication of Q.flowstatesig as an ITU-T Recommendation could result in serious interoperability issues, and would also ignore the standing collaboration agreements between the IETF and the ITU-T. The IESG recommends that an Internet Draft be prepared and submitted to the IETF for discussion in the "IPv6 Maintenance (6MAN)" Working Group. This Internet Draft needs to contain a definition of the IPv6 option and a specification of the protocol mechanisms it is intended to be used with, in addition to an assignment request for IANA. References to ITU-T requirements and intended usages are highly recommended. Please ensure that such references are publicly available for review by any IETF participant. If this Internet Draft achieves consensus for publication and its publication is approved by the IESG, IANA will assign the requested option number. The Internet Area Directors Jari Arkko and Ralph Droms are the appropriate contacts for discussing the progress of this Internet Draft during the IETF process. A second, similar concern of the IESG is related to the "QoSSignal" DiffServ codepoint mentioned in Q.flowstatesig. IANA assignment of a new DiffServ codepoint requires an IETF Standards Action. As above, this assignment can only happen following the publication of an RFC, and Q.flowstatesig cannot be published as an ITU-T Recommendation before this assignment has concluded. In support of this assignment request, the proponents are tasked to submit an Internet Draft detailing the motivation and usage mechanism of the requested codepoint to the "Transport Area Working Group (TSVWG)", which is maintaining the DiffServ architecture. The Transport Area Directors Magnus Westerlund and Lars Eggert are the appropriate contacts for discussing proposals in this area. Third, the IESG notes that SG11 has not yet acted on the question from the Transport Area in its liaison statement sent in May 2008 (https://datatracker.ietf.org/liaison/447/), which requested: "We are looking forward to receiving a liaison statement where SG11 provides an outline of the technical details of its proposed solution, with a focus on where the solution proposed by SG11 affects protocols and specifications that are under IETF change control." The IESG is of the opinion that such an analysis, together with the resulting list of any potential changes to IETF specifications and required IANA assignments, is an essential requirement to coordinate any standardization activity in a timely manner. The IESG identified the two issues raised above during its review of the material SG11 has so far provided on Q.flowstatesig, but additional complications may arise from material that is not yet available to the IETF. The IESG would hence like to reiterate the request that SG11 provides an outline of the technical details of its proposed solution, with a focus on where the solution proposed by SG11 affects protocols and specifications that are under IETF change control. Finally, the IESG would like to extend their thanks to Dr. John Adams for his continued participation in the IETF on this topic; most recently, in the NSIS Working Group meeting. As documented in Q.flowstatesig, some differences exist between flow-state-aware access QoS control and RSVP, although the general concepts appear similar. The IESG is not aware of any proposals to address ITU-T requirements for Q.flowstatesig [ITU-T Y.2121] using a new NSIS signaling application. Any such proposal will most likely require a "birds of a feather" (BOF) session at an upcoming IETF meeting to discuss its merits. The IESG would note that IETF participants are likely to ask for an analysis why none of RSVP [RFC 2205], the NSIS QoS NSLP [draft-ietf-nsis-qos-nslp], and a new NSIS signaling application is deemed suitable by SG11 to fulfill the requirements in Y.2121. A publicly available analysis of the arguments will simplify the work on any extension required for ITU-Ts current proposal for solving the ITU-T requirements. Summarized Requests: (1) The IESG requests that SG11 acknowledges that based on the general agreement between the ITU-T and the IETF, SG11 will not approve and publish Q.flowstatesig as an ITU-T Recommendation before any required IETF consensus processes and IANA assignments have completed. (2) The IESG requests that SG11 analyze if Q.flowstatesig requires any additional extensions to IETF protocols or any additional IANA assignments beyond those already identified in this liaison statement, and that SG11 communicates those to the IETF. Upon receiving this analysis, the IESG will recommend how to SG11 can initiate efforts to request such changes or assignments within the IETF process.