The MPLS WG Archive

["Ash, Gerald R (Jerry), ALABS" <gash@att.com>]

Loa> Could you do me a favor and have a look at:
Loa> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-andersson-mpls-g-chng-proc-00.txt

Scott> this ID was brought up in a meeting I am at in the ITU - there 
Scott> is some concern about it - I have asked that people with 
Scott> concerns please send their concerns in.

The requirements decision processes in the I-D should give some weight to the 'strength' of the requirements source and proponents.  

E.g., a concern was raised in a recent discussion on the iesg@ietf.org email-list "RE: Last Call: CR-LDP extensions for ASON to Informational", where GMPLS/ASON requirements were put forward by ITU-T, with many SPs as proponents, but did not get adequate attention or evaluation, and were perhaps even rejected out of hand.  The unfortunate consequence of this outcome is that now 2 'GMPLS/ASON signaling' (RSVP-TE) standards have emerged, perhaps with interoperability issues.

The decision steps in the I-D are quite vague, and it is unclear that these will do much to rectify this concern, e.g.:

In Section 2.2.2 "The MPLS and CCAMP working group chairs in conjunction with the Area Directors will determine if the particular problems raised ... should be evaluated by a working group... based on the mailing list discussion."
In Section 2.2.4 "The rewg will evaluate the problem statement ID and based on the evaluation make a recommendation to the IESG/IAB."

Nothing is said as to criteria applied to the 'mailing list discussion' (could be dominated by one loud person with a particular view), or how the 'rewg will evaluate the problem statement'.  The decision process appears to remain the status quo, i.e., 'rough consensus', wherein a small oligarchy of ADs, WG chairs, and perhaps a few SMEs appear to decide (especially problematic in 'no response' decision, as stated above).

Additional teeth could put in place to give a more comprehensive review/decision process to overcome these identified problems, e.g.,:

a. for certain categories of problem statements/requirements, put a 'design team' in place to evaluate/recommend a course of action.
b. problem statements signed onto by a >threshold # of SPs/vendors could have such 'design team' evaluation.

Jerry Ash