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

From: Bala Rajagopalan <[email-masked]>
Date: Thu, 27 Feb 2003 22:57:56 -0500

Just ran into this ID. The flow chart, as usual,
was too complicated for me to comprehend, to I
ran it through the decoder software that IESG 
provides to unscramble its policy statements
(see http://www.ietf.org/iesg/policy_faq/demystify.exe).
The flow chart was then rendered human-readable
as follows:

	MPLS and GMPLS Change Process 
	-----------------------------

        +-------------------------+ 
        |   Receive New ID        | 
        +-------------------------+
                   |
                   | 
                   V
       +-------------------------------------+              
       | Briefly wonder about the resilience |         
       | of the MPLS/GMPLS bandwagon.        |                         
       | Start review.                       |
       +-------------------------------------+             
                  |  
                  |  
                  V
       +-----------------------------------+ 
       | Does the draft contain the term   |  Yes 
       | "ASON"?                           |-------> TRASH 
       +-----------------------------------+
                  |   
                  | No
                  V
        +----------------------------------+ 
        | Does the draft contain the term  |   Yes
        | "UNI"?                           |--------> Incinerate
        +----------------------------------+                    
 	           |
	           | No 
	           V
        +-------------------------------+   Yes, I-NNI 
        |   How about "NNI?"            |-----+----> TRASH 
        +-------------------------------+     |
                  |                           | E-NNI
                  | No                        +-----> Shred 
	           V
        +-------------------------------+ 
        | Does the draft mention Call   |   Yes
        | vs Connection control?        |-------> Send a sample
        +-------------------------------+         of draft to CDC,
                  |                               incinerate rest
                  | No
                  V
        +-------------------------------+ 
        | Does the draft have the term  |  Yes
        | "G.xyz." in the title?        |---------> TRASH
        +-------------------------------+  
                  |		         
                  | No
                  V
        +-------------------------------+ 
        | Draft has progressed too far. |
        | Send to Curtis for review.    |
        +-------------------------------+
                  |
                  | 
                  V
             |            |
             |    TRASH   | 
             +------------+  

Seems a bit draconian and no wonder, people are anxious 
about the process and expect the worst.  Still, I believe 
this will help in limiting the generation of useless drafts 
and protocol extensions to
WGs within the IETF and prevent outside groups from doing the same. 

Regards,

Bala Rajagopalan
Tellium, Inc.
2 Crescent Pl.
Ocean Port, NJ 07757
USA
Ph: +1-732-923-4237
Email: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 28 Feb 2003 11:07:29 -0500

In message <[email-masked]>, Bala R
> The flow chart was then rendered human-readable

AFAIK - When IESG members run the compiler they don't produce exe
files.  :-)

> 	MPLS and GMPLS Change Process 

Not bad.  I think you're OK up to here.

I think that either "call control" or "connection control" warents a
trip to the dumpster.

Not true.  Examples:

  2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video
       (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco,
       D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. October 1998.
       (Format: TXT=43166 bytes) (Status: PROPOSED STANDARD)

  3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi.
       January 2001. (Format: TXT=16292 bytes) (Status: PROPOSED STANDARD)

  3095 RObust Header Compression (ROHC): Framework and four profiles:
       RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M.
       Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. Hakenberg, T.
       Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. Svanbro, T.
       Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: TXT=368746 bytes)
       (Status: PROPOSED STANDARD)

  3267 Real-Time Transport Protocol (RTP) Payload Format and File
       Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive
       Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, M. Westerlund,
       A. Lakaniemi, Q. Xie. June 2002. (Format: TXT=110652 bytes) (Status:
       PROPOSED STANDARD)

  3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise
       (CN). R. Zopf. September 2002. (Format: TXT=17018 bytes) (Status:
       PROPOSED STANDARD)

These have plenty of G. and H. numbers in them and none of them are
informational.  All of them make sense (for example: no severe scaling
issues).

I didn't realize I played such an important role in this process.  All
this time I thought I was just making technical comments.

Sounds like you're still upset that I didn't like the OIF-UNI and/or
you don't like technical comments regarding the feasibility of
proposed encapsulation of G.709.  A primary point regarding OIF-UNI is
that ATM-UNI service (ie: SVCs) never took off therefore the last
thing we needed was a UNI for optical.  In other words, there is no
credible requirement.

We'll have to see how the market acceptance of OIF-UNI goes.  So far
it looks about as alive as CR-LDP did for a few years.  The market
certainly put an end to LANE, NHRP, MPOA, and the whole idea of
modeling ATM as a LIS.  Check the IPATM and ION archives if you'd like
to read my comments on those standards which were strongly supported
by SDOs outside the IETF.

I'm sorry that you don't like technical comments made about the G.709
compressions.  Apparently some people think the IETF should just
rubber stamp everything because it came from the ITU even if there are
scalability issues which make deployment infeasible.

> WGs within the IETF and prevent outside groups from doing the same. 

The IETF can't stop other SDOs from creating useless protocols and
protocol extensions and some have become quite good at it.  :-)

Curtis