RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

"Ash, Gerald R (Jerry), ALABS" <gash@att.com> Thu, 06 March 2003 01:25 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 05 Mar 2003 17:27:07 -0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Date: Wed, 05 Mar 2003 20:25:13 -0500
Message-ID: <28F05913385EAC43AF019413F674A01704A1782E@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
Thread-Index: AcLdei7OCiKqDIIjQ0SYJfNrsPJQbQAHvIogAXZulfA=
From: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
To: mpls@UU.NET, ccamp@ops.ietf.org
Cc: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>

It seems that progress has been made on this thread in initiating a liaison process, etc.

However, a problem still not addressed is:

'problem ga': GMPLS/ASON requirements were put forward by ITU-T but did not get adequate attention/evaluation in IETF, with the unfortunate outcome that now 2 'GMPLS/ASON signaling' (RSVP-TE) standards have emerged, 'itu-gmpls' & 'ietf-gmpls', most likely with interoperability issues.

'itu-gmpls' would appear to be a 'major extension' in the context of http://www.ietf.org/internet-drafts/draft-iesg-vendor-extensions-00.txt.  As such, none of the following recommendations seem to have been followed:

"- All major extensions to IETF protocols should be done with direct involvement of the IETF
-  The decision on whether an extension is major or minor should be done with the direct involvement of the IETF
- Extensions should be done by IETF working groups using normal IETF processes
- Major extensions should be ... checked by the IETF community to be sure that the extension does not defeat safeguards designed into the protocol, such as security functions, or undermine its architectural integrity
- No individual, vendor, SDO or forum should be able to create what is viewed to be a major extension to an IETF protocol on its own and legitimately be able to claim that implementations that implement the extension are compliant to the IETF specification."

Could these recommendations now be addressed, perhaps by a team of SMEs, to evaluate/recommend a course of action?  It doesn't matter whether or not this is a formally sanctioned design-team, or a self-organized team of SME's who represent the component SDO interests, as long as a good technical solution emerges.  I've observed that a 'team' of SME's has now 'organized' on this list (on this thread), and in a sense is addressing problem ga, although they're somewhat adversarial in tone at the moment :-).  Could this energy/creativity be targeted at positive technical solutions in terms of the above recommendations?

It's unclear if this kind of problem fits within the scope of the 'problem statement' of draft-andersson-mpls-g-chng-proc, which BTW provides no 'problem statement' as the I-D itself requires.

In any case, problem ga is still there, and to me should at worst not be repeated, and at best be solved & not repeated.

Jerry Ash