Sig MIB, NCS SF Objects -1: CM or MTA config?

I was hoping for more comments on the issue summary but since everyone seems to agree, let's start separate threads.

> 1/ Should the MTA MIB provide means to create dynamic DOCSIS 
> SFs for NCS Signaling, or should it simply be left to the CM 
> config file?

I have polled a couple of MSOs deploying PacketCable voip service. Everyone seems to be using static docsis SF in the CM config file to set up special flows for NCS traffic. 

If these MTA sig mib objects are not used today, do we need them at all? If not, we can simply delete them and the issues raised by some of you are closed as far as the SigMIB is concerned.

Setting up NCS SF in the CM config - pros:
 o  used by operators, proven and operationally preferred 
 o  no security risks due to SCN name authorization
 o  all special SF settings viewed by the cable data provider in one config file
 o  pre-provisioned on the CPE device for all embedded CM in E-MTAs, whether or not the MTA telephony service is enabled and whether the MTA boots up


Setting up NCS SF in the MTA config - pros:
 o separate telephony from high speed data CPE config settings
 o more scalable (SF triggers for apps needing special QoS are inherently part of the application level configuration)
 o pre-provisioned on the CMTS via SCN and on CPE device in the MTA config file, activated only when MTA boots up


Any additionals pros for one or the other?
Any opinions on whether we should keep those objects at all?
Thanks,
Jean-François