Draft liaison to ITU SG15 on process

"Adrian Farrel" <adrian@olddog.co.uk> Thu, 29 March 2007 11:41 UTC

Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWt0x-0007g5-Uo for ccamp-archive@ietf.org; Thu, 29 Mar 2007 07:41:59 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWt0w-00046d-Ce for ccamp-archive@ietf.org; Thu, 29 Mar 2007 07:41:59 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1HWsrW-000HuK-EF for ccamp-data@psg.com; Thu, 29 Mar 2007 11:32:14 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.7
Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1HWsrS-000HtC-OO for ccamp@ops.ietf.org; Thu, 29 Mar 2007 11:32:12 +0000
Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1HWsrQ-00067N-SH for ccamp@ops.ietf.org; Thu, 29 Mar 2007 11:32:09 +0000
Received: from your029b8cecfe ([217.158.132.8] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Mar 2007 12:32:06 +0100
Message-ID: <0e5101c771f5$bf431800$ea138182@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: ccamp@ops.ietf.org
Cc: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, Ross Callon <rcallon@juniper.net>, Dave Ward <dward@cisco.com>, Scott Bradner <sob@harvard.edu>
Subject: Draft liaison to ITU SG15 on process
Date: Thu, 29 Mar 2007 12:21:43 +0100
Organization: Old Dog Consulting
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 29 Mar 2007 11:32:07.0036 (UTC) FILETIME=[E1AB13C0:01C771F5]
X-Originating-Rutherford-IP: [88.96.235.142]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e

Hi,

One of the larger issues raised by a recent liaison from ITU-T Study Group
15 is on process and how we can continue to build a better relationship
between SG15 and CCAMP.

Here is a draft response.

Comments please by end of April 5th.

Thanks,
Adrian and Deborah
===

To: ITU-T SG15
From: IETF CCAMP
Cc: Yoichi Maeda, Stephen Trowbridge, Kam Lam, Scott Bradner, Ross Callon,
Dave Ward
For Action
Deadline: 25th June 2007

Subject: Cooperative Relationship between ITU-T SG15 and CCAMP

CCAMP 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. In order to crystallise this process, the IETF has recently
published RFC 4775 ("Procedures for Protocol Extensions and Variations") and
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, where 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 (COM 15-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