Subject: New Liaison Statement, "Cooperative Relationship between ITU-T SG15 and CCAMP"

From: Adrian Farrel (IETF CCAMP WG) <[email-masked]>
Date: Sun, 08 Apr 2007 08:25:56 -0400

Title: Cooperative Relationship between ITU-T SG15 and CCAMP
Submission Date: 2007-04-08
URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=318 
Please reply by 2007-06-25

From: Adrian Farrel(IETF CCAMP WG) <[email-masked]>
To: ITU-T SG15(Greg Jones <[email-masked]>)
Cc: Yoichi Maeda <[email-masked]>
Stephen Trowbridge <[email-masked]>
Kam Lam <[email-masked]>
Scott Bradner <[email-masked]>
Ross Callon <[email-masked]>
Dave Ward <[email-masked]>
CCAMP Mailing List <[email-masked]>
Reponse Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Technical Contact: Adrian Farrel <[email-masked]>
Deborah Brungard <[email-masked]>
Purpose: For action 
Body: The CCAMP working group of the IETF thanks you for your liaison
entitled "Liaison Statement to CCAMP responding to ccamp liaison
of 21 February 2007". The last paragraphs of your liaison discuss
the cooperative relationship between ITU-T SG15 and the IETF's
CCAMP working group and we would like to respond to these issues
separate from the technical discussions.

Over the last few years we have seen an increase in cooperation
between our organisations, and we believe that this is to the
considerable benefit of the industry. CCAMP has regularly sent a
liaison representative to ITU plenary and interim meetings, and
useful comments and feedback have been received from these 
meetings as a result of review of IETF Internet-Drafts in 
progress. Additionally, Mr. Lyndon Ong has been allocated a
regular slot on the CCAMP meeting agenda at each IETF meeting to
update the working group on the progress of the ITU-T in areas of
interest to CCAMP.

While we consider that the free flow of information and the review
feedback on CCAMP work to be very valuable, we are also conscious
that the mechanisms of the ITU-T and IETF are very different. 
Therefore we make every attempt to avoid wasting your precious
meeting time, and only ask for review when we consider the material
to be stable and pertinent.

In your liaison, you say:

   ITU-T SG 15 has been relying on a collaborative relationship with
   IETF ccamp to provide the protocol support for ASON.  This
   collaborative work should allow the industry to take advantage of
   the different expertise in each of the Standards Development
   Organizations. Q.14/15 has not developed protocol specific
   Recommendations for ASON since 2003, based on an expected
   collaborative technical relationship, in which IETF ccamp would
   provide protocol solutions that fully meet the ITU-T ASON
   requirements.

We appreciate your engagement with this process and we believe that 
it is to the best interests of the industry and to all participants
in both bodies. The liaison process provides a mechanism to engage
between the two bodies, and it is clear that the earlier 
communication occurs, the less the chance of misunderstanding or
parallel development.

In order to describe the IETF's view of the procedures and 
processes for extending and varying IETF protocols, the IETF has
recently published RFC 4775 ("Procedures for Protocol Extensions 
and Variations"). In order to describe the mechanisms by which 
other bodies can influence the development of MPLS and GMPLS 
protocols, the IETF has just consented for publication draft-
andersson-rtg-gmpls-change-08.txt ("Change Process for 
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Protocols and Procedures"). The net effect of these documents is 
to give the ITU-T clear access into the IETF process and to commit
the IETF to work with the ITU-T to develop solutions to requirements
that originate in the ITU-T.

You state further:

   However, the effectiveness of this SDO liaison relationship
   could be improved.

We agree that there is always room for improvements on both sides.
Some issues will arise from differences in established behaviour 
within the two bodies, and we are always grateful when you point 
out opportunities to improve the mechanisms that we have in place.
Although neither the ITU-T nor the IETF is likely to make a major 
change to its operational procedures, there are doubtless very many
small areas where improvements could be made.

One such area of improvement might be to relax the communication 
style and mechanisms allowing a more free and rapid exchange of 
technical opinions amongst the participants. Although this cannot 
replace the liaison relationship as a means for exchanging the 
official and consented views of each body, we could gain a lot from
increasing the level of discussion rather than relying on the 
relatively infrequent use of liaison statements. We would welcome
your suggestions on how to achieve this - the CCAMP mailing list
remains open and might be a suitable vehicle for this type of
communication.

As you go on to say:

   We observe that IETF ccamp has responded to some of the
   technical issues raised by suggesting that the ITU-T participants
   should provide input directly, to the work in ccamp.  We agree
   that having participants involved in both the  ITU-T and IETF
   improves the communication process.  We would like to confirm
   that this individual participation is not being suggested as a
   substitute for the liaison relationship.  A liaison statement or
   ITU-T Recommendation represents the consensus of the members
   of the ITU-T.  An individual participating in the work of ccamp is
   not authorized to represent or negotiate on behalf of the ITU-T.

We understand the points you make. Nevertheless, we would like to 
continue to encourage individual participation. Individuals who are
interested in the development rather than the review of protocol 
solutions would be well advised to bring their ideas to CCAMP early
in the process. In the same way, we would advise individuals 
interested in the work of the ITU-T to become involved there and 
not to wait for the opportunity to review the material when it is 
liaised to the IETF as it nears completion.

You cite a specific area for improvement in your liaison, and we are
grateful for your attempt to isolate specifics since it is far more
easy to learn from examples than from general statements.

   One particular area for improvement of the liaison relationship is
   communicating the disposition of ITU-T comments related to the
   interpretation of ASON requirements.  For example comments
   provided on, draft-ietf-ccamp-gmpls-ason-routing-reqts-02 (now
   RFC 4258) and draft-ietf-ccamp-gmpls-ason-routing eval-00 (now
   RFC 4652) were not included in the published RFC and the rational
   for this decision has not been communicated.

We are disturbed by your identification of these specific concerns at
this time in our communication. Due to the time that has lapsed since
the events that you mention, it is hard to provide appropriate and 
definitive discussion.

We believe that the discussion of RFC 4258 and lack of response refers 
to a liaison received from SG15 in February 2004. Although the issues 
received full discussion on an open mailing list and included comments
from no fewer than seven regular Q14/15 participants, and although the
design team that produced the final text of the RFC included Q14/15 
participants who could have reported the agreement and rationale back
to Q14/15, we agree that it would have been helpful to liaise the 
outcome of these discussions to you direct.

In a subsequent liaison (COM15-LS18) in April 2004, you stated:

   Q.14/15 would like to thank the IETF CCAMP WG and
   especially the members of the ASON Routing Requirements
   Design Team for their efforts to understand and capture ASON
   Routing Requirements for the future work in IETF.

   Q.14/15 would like to continue cooperative work with IETF,
   extending this to the application of routing protocols to support
   the ASON requirements.

We interpreted these sentences to mean that you were aware of the 
completion of RFC4258 and that you were satisfied with the results.

Review of the material that led to RFC 4652 was first liaised to CCAMP
by SG15 in May 2005 (COM15-LS57-E) in response to a request for review
issued by CCAMP earlier that same month. The liaison from SG15 was 
marked "For Information" and our understanding of this label (as noted
in section 2.2.1.1.6 of RFC 4053) is that "The liaison statement is to
inform the addressee of something, and expects no response." In the 
light of the current situation it would have been wise for the chairs
to have confirmed that this was really the intended purpose of the 
liaison, but we should note that 50% of the author team for RFC 4652 
were regular Q14/15 attendees who could have reported the status and 
decisions (albeit informally) to the Question.

Subsequent liaisons on the material of RFC 4652 included:

   November 2005 (Q12-14 Interim meeting-LS006-E)
   "Q.14/15 ... strongly supports CCAMP's continued work to
   address ASON requirements in the routing protocols."

Your recent liaison concludes:

   ITU-T SG15 continues to be interested in providing clarification or
   validation of IETF ccamp interpretation of the ASON requirements
   and therefore request that in future any documents under
   development that are potentially applicable to ASON be liaised so
   that ITU-T can validate the documents against the ASON
   requirements.

   We look forward to receiving your response and hope that we can
   continue to build a cooperative and productive relationship between
   ccamp and SG 15.

While we cannot promise to send every piece of work that is potentially
applicable to ASON, we can and will liaise all work where there is a
definitive intention of applicability to ASON.

CCAMP continues to be grateful to SG15 for its efforts to ensure that 
the ASON architecture and requirements are correctly interpreted, and
appreciates that this will lead to protocol solutions that are of 
value to the industry.

Best regards,

Adrian Farrel and Deborah Brungard
Co-chairs, IETF CCAMP Working Group
Attachment(s):
No document has been attached