Zhi, > (e) These documents were never taken seriously (This is the first email I > sent: http://ops.ietf.org/lists/ccamp/ccamp.2002/msg00918.html -- but of > course no one responded) Reminder, I responded to your email on June 18, very shortly after you posted (my email to you is attached below). That I did this off the list was probably a mistake. We (you, your co-authors, Adrian and I) then had a prolonged exchange of emails about the draft. Adrian sent you extensive comments on the draft highlighting concerns, suggesting text, and pointing out nits. That you have a reasonably long list of acknowledgements and contributors suggests that the draft was not ignored. As I commented in the attached email to you, "Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such?" I still maintain that this would be the correct way to handle this: bring the requirements to CCAMP as a requirements draft, thrash them out, and get the necessary extensions adopted in CCAMP. Rather, the ITU has developed protocol extensions for GMPLS, something outside the charter of the ITU I believe. Jerry -----Original Message----- From: Ash, Gerald R (Jerry), ALASO Sent: Tuesday, June 18, 2002 12:58 PM To: 'Zhi-Wei Lin' Cc: Ash, Gerald R (Jerry), ALASO; 'Adrian Farrel' Subject: RE: new draft: GMPLS for ASON Hi Zhi, > I've uploaded a new draft covering the GMPLS usage and extensions to > support the ASON requirements. This document proposes appropriate > extensions towards the resolution of additional requirements identified > and communicated by the ITU-T in support of ITU's ASON standardization > effort, and only provides the extensions for RSVP-TE signaling. Among > the major extensions include support for the concept of "call", as well > as support for setting up soft permanent connections. > > http://www.ietf.org/internet-drafts/draft-lin-ccamp-gmpls-ason-rsvpte-00.txt Looks good. I've attached some excerpts below from the (unpublished) IETF-54/CCAMP meeting minutes. These also identify crankback, restart, etc. as 'gaps' needing to be filled. I guess most of these are being worked on, including restart and crankback http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-03.txt (Adrian is currently providing a significant extension for the 04 version of the crankback draft). Would it be worthwhile to somehow 'package' the needed ASON extensions into a proposed GMPLS upgrade and presented to CCAMP as such? Your comments/suggestions are appreciated. Thanks, Regards, Jerry %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Steve Trowbridge Outlined a variety of "gaps" in the current work: - Call and connection separation - Additional error codes/value - Restart mechanisms - Support for crankback - Support for soft permanent connection See proceedings for details. Eric Mannie: Referring to slide "Identified Gaps". Gaps seem to be very small. Most of the points are solved, can be easily solved, or are in the process of being solved. Trowbridge: This was a preliminary scan. Further review, might turn up more issues. Technologies are similar, so lets identify and minimize gaps. Dimitri: ITU requirements precede much of IETF work. Preliminary discussions indicate that the current gaps are covered by existing protocol work. Areas where additional work will be required are probably minimal, but need to be looked at. IETF may gain final improvements by looking at ITU work. Yong Xue: ITU is working on v2 ASON document so more things could turn up as "gaps". Further communication between ITU and IETF should continue. Trowbridge: Technology will evolve within both organizations. Should expend effort to make sure that they evolve together. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Osama Aboul-Magd -- draft-aboulmagd-ccamp-call-conn-separation-00.txt. Draft addresses one of the issues that Tolbridge highlighted in his talk - call and connection control separation. Kireeti: There is an explicit statement from ITU requiring this. There is nothing in the charter about this. This is good stuff. Ron and I will go through a charter revision with Ads and discuss putting this in the charter. Also need to address other gaps that were raised by ITU. Scott: When you propose to add something to WG, it would be helpful to state where it fits in the existing charter OR how and why charter should be extended. Eva: I think that it fits into the character as a requirement to the signaling protocols. Scott: OK - that is a good clean explanation that might save chairs some time. Yong: I second Eva's comment. Kireeti: Need to figure out how to address other issues as well. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%