[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: CP-->MP Issue (was RE: Polling for new WG I-Ds)



Lou and Diego, all

Two points. 

If we were to ask could you live without the CP->MP feature what
response would we get versus asking if CP->MP is a soft requirement.

The other point that baffles me is there is not one "standard" MP that
I'm aware of so really we are talking many variations of MP to a
standard CP. So how do you define a CP to variations of MPs? The
document currently oversimplifies this aspect IMHO.

Thanks,
Don

> -----Original Message-----
> 
> Diego,
>          In my experience in talking about this feature with 
> carriers is that some (but not all) will require such 
> symmetric behavior.  I think the other rational for this 
> feature are irrelevant.  Again, the sole reason I've seen for 
> this requirement is that to deploy MP->CP some will require 
> that there be support for CP->MP.
> 
> I therefore think the definition of CP->MP *is* required.  
> There are multiple options for meeting this requirement, but 
> the solution must provide the "fallback" capability for 
> services existing at the time of the initial MP->CP 
> transition and those created after the transition.
> 
> I think a SHOULD level requirement is sufficient for this 
> capability, but I'd be interested if those representing 
> carries on the list differ.
> 
> Lou
> 
> At 03:09 AM 8/24/2006, Diego Caviglia wrote:
> 
> 
> >In my mind the CP->MP feature can be useful for mainly two purposes:
> >1)    symmetricity with the companion feature (MP->CP)
> >[...]
> >
> >We (the authors of the ID) agreed with Dimitri that CP->MP is not a 
> >must and I have no problem to move it to should/shall/may state.
> >
> >[...]
> >However the focus of the ID is on MP->CP handover and if the 
> community 
> >is strongly against of CP->MP even in the form of a should/shall/may 
> >requirement we can strip this out.
> >
> >Regards
> >
> >Diego
> 
> 
>