RE: Dropping the Local Overbooking Multiplier (LOM) method from D S-TE specs?

Hi!
comments in-line.

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email protected]]
> Sent: Tuesday, June 03, 2003 7:28 PM
> To: [email protected]
> Cc: Ash, Gerald R (Jerry), ALABS; Francois Le Faucheur 
> (flefauch); Lai,
> Wai S (Waisum), ALABS
> Subject: RE: Dropping the Local Overbooking Multiplier (LOM) 
> method from
> DS-TE specs?
> 
> 
> All,
> 
> I had proposed earlier:
> 
> > Can anyone give a practical example of where LOM is needed? 
> > Unless we see that, my preference would be to drop it.   
> 
> Since posting that, some examples have been given (on the 
> list and privately) that perhaps illustrate how LOM can be 
> used in practice.
> 
> Furthermore, based on the discussion so far:
> 
> 1. many people support leaving LOM in because they're 
> reluctant to give up the extra flexibility (even though they 
> don't offer specific supporting examples).
> 2. many people feel that the LOM extension is very simple, 
> therefore why the concern, just leave it there.
  
  And possibly a third category:
  3. people who think the LOM extension is relatively simple
  and think LOM has potential usage. 
  [On complexity issue : see my previous e-mail,
   For specific example: see my previous e-mail on issues and
				 the e-mail response to Dimitry's e-mail]

> 
> Also, I argued against having LOM progressed separately, I 
> think that would just complicate matters, and leave the BC 
> models, Proto extensions, etc. in a state of limbo (possible 
> awaiting a LOM extension later).  I had argued to either keep 
> LOM, or drop LOM, but not leave it in the 'in between' state.
> 
> Overall, I don't think the case has been made to drop LOM, 

  Personally, I agree with this view [given that LOM is already
  an optional feature]
  
  Thanks,
  sanjay	
  
> and, given that, I believe the better option is to leave LOM 
> as is and not progress it as a separate effort.
> 
> Thanks,
> Jerry
>