Re: Draft liaison to ITU SG15 on process

["tom.petch" <[e-mail]>]

Adrian

Yes, a subtle change but for me, better.

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[e-mail]>
To: "tom.petch" <[e-mail]>; <[e-mail]>
Cc: "Brungard, Deborah A, ALABS" <[e-mail]>; "Ross Callon"
<[e-mail]>; "Dave Ward" <[e-mail]>; "Scott Bradner"
<[e-mail]>
Sent: Monday, April 02, 2007 7:37 PM
Subject: Re: Draft liaison to ITU SG15 on process


> 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" <[e-mail]>
> To: "Adrian Farrel" <[e-mail]>; <[e-mail]>
> Cc: "Brungard, Deborah A, ALABS" <[e-mail]>; "Ross Callon"
> <[e-mail]>; "Dave Ward" <[e-mail]>; "Scott Bradner"
> <[e-mail]>
> 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" <[e-mail]>
> > To: <[e-mail]>
> > Cc: "Brungard, Deborah A, ALABS" <[e-mail]>; "Ross Callon"
> > <[e-mail]>; "Dave Ward" <[e-mail]>; "Scott Bradner"
> > <[e-mail]>
> > 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
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>