Re: Draft liaison to ITU SG15 on process

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 02 April 2007 17:44 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 1HYQZn-00035H-5h for ccamp-archive@ietf.org; Mon, 02 Apr 2007 13:44:19 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQZm-000843-EE for ccamp-archive@ietf.org; Mon, 02 Apr 2007 13:44:19 -0400
Received: from majordom by psg.com with local (Exim 4.63 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1HYQTk-00030e-0T for ccamp-data@psg.com; Mon, 02 Apr 2007 17:38:04 +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.141] (helo=heisenberg.zen.co.uk) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1HYQTc-0002zr-7x for ccamp@ops.ietf.org; Mon, 02 Apr 2007 17:38:00 +0000
Received: from [88.96.235.142] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1HYQTZ-00010p-RV for ccamp@ops.ietf.org; Mon, 02 Apr 2007 17:37:55 +0000
Received: from your029b8cecfe ([217.158.132.86] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Apr 2007 18:37:49 +0100
Message-ID: <03f301c7754d$9fbd1890$0a23fea9@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: "tom.petch" <cfinss@dial.pipex.com>, 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>
References: <0e5101c771f5$bf431800$ea138182@your029b8cecfe> <035601c77542$b2159a40$0601a8c0@pc6>
Subject: Re: Draft liaison to ITU SG15 on process
Date: Mon, 02 Apr 2007 18:37:35 +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: 02 Apr 2007 17:37:50.0260 (UTC) FILETIME=[A2805740:01C7754D]
X-Originating-Heisenberg-IP: [88.96.235.142]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0

Thanks Tom,

How about if the relevant paragraph read...

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.


Adrian

----- Original Message ----- 
From: "tom.petch" <cfinss@dial.pipex.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>; <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>
Sent: Monday, April 02, 2007 5:09 PM
Subject: Re: Draft liaison to ITU SG15 on process


> Adrian
>
> No doubt you are familiar with RFC4775, to which you refer, but I would 
> suggest
> that it may not be of much assistance in this case.
>
> It is written in IETF-speak and, as such, may be impenetrable to those
> who are not already involved in the IETF, and, after spending much of the 
> first
> eight
> pages telling people to find an AD/WG and submit an I-D, then mentions in
> passing that where a liaison exists, then that should be used; which is 
> the case
> here.
>
> So I would suggest amending the reference to it, using it as an example of 
> the
> IETF's wishes for other SDOs to engage but pointing out that, as it says, 
> as
> long as we have a liaison, then that is the best place to engage; and as 
> early
> in the process as possible.
>
> I think that the failures, such as they are, arise because of a tendency 
> to
> produce the polished article, but too late, whereas a back of the fag 
> packet a
> few months earlier would have been more productive. But this liaison may 
> not be
> the right place to express more of  that point of view than you are 
> already
> doing.
>
> Tom Petch
>
> ----- Original Message -----
> 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>
> Sent: Thursday, March 29, 2007 1:21 PM
> Subject: Draft liaison to ITU SG15 on process
>
>
>> 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
>>
>>
>>
>
>
>
>