Kireeti, if we can agree that we have two problems and from the perspective of an external SDO they are closely coupled. One way of moving forward would be to develop two IDs in parallel. The first based on the existing anderson-mpls-g-change-proc, modified to state explicitly that requests for changes by external SDOs are exempt from this process. The second draft would address the liaison process. The key issue with changes requested by external SDOs is that in general they will be based on the desire to apply (G)MPLS protocols to connection management of connection oriented circuit switched (COCS) networks for the benefit of COCS clients - i.e. to applications that are well outside the "normal" IETF problem space. To keep the activity focussed (as suggested in some earlier emails) perhaps we could limit the scope to the sub ip area only (at least initially). I think that Steve Trowbridge in an earlier email (copy below) provided a good summary of the objectives of the liaison process.
-----Original Message-----
From: Kireeti Kompella [mailto:kireeti@juniper.net]
Sent: Monday, March 03, 2003 5:02 PM
To: Stephen Trowbridge
Cc: mpls@UU.NET; ccamp
Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Hi Steve,
On Mon, 3 Mar 2003, Stephen Trowbridge wrote:
> Lets try to zero in on what the problem really is.
Good idea.
> I think that liaison handling (or the lack thereof) is not just a
> problem. It is THE problem.
I disagree. I think there are two problems, and both are important.
<snip>
<insert for Steve Trowbridge>
IETF has one set of requirements for the kinds of networks that they envision and are within their charter. They develop an architecture and protocol solutions to support those requirements. ITU-T has an (overlapping but different) set of requirements for the kinds of networks they envision (including lots of TDM & WDM traffic that doesn't necessarily carry IP, etc.). Nobody says that the additional ITU-T requirements are valid for the IETF application, or that IETF must solve the ITU-T requirements with IETF developed protocols (they can choose to, but there is no obligation).
When the ITU-T brings these requirements to the IETF's attention, there are a variety of perfectly reasonable responses:
- The IETF can say "That requirement is important for us also, let's work
toward a common solution".
- The IETF can say "That requirement is not important for the IETF scope
of work, but we can see how it is important for yours. From our
experience with the protocol and our desire for sanity in the protocol
and all of its extensions, we can offer you the following advice about
how the protocol can best solve your problem ..."
- The IETF can say "That requirement is not important for the IETF scope
of work and we are not particularly interested in helping with a solution -
you are on your own, but please assign any protocol codepoints through
IANA and document your extensions as an info RFC so that we can prevent
any conflict with other extensions.
They could EVEN say "We think you might have misunderstood the requirements: do you think that the following restatement of the problem would allow your needs to be met with the current protocols: ..."
But the answer that I would have trouble with would be the IETF saying "That requirement is not important for the IETF scope of work, and therefore no solution should be developed for your problem AT ALL. After all, if it is not important for IETF, it must be irrelevant for everybody."
Of course, without a liaison process, I don't know how we get any of these responses. Incoming liaisons seem to hit the dustbin before they get serious consideration regarding which of the above response types might be most appropriate. Regards, Steve
<end inserted text>
Malcolm Betts
Phone: +1 613 763 7860 (ESN 393)
FAX: +1 613 763 6608 (ESN 393)
email: betts01@nortelnetworks.com