RE: Sig MIB, NCS SF Objects -1: CM it is

   This note provides the IPCDN wg consensus on the MTA Signaling MIB
objects related to the establishment of NCS Service Flows. It took me
longer than I thought to summarize the input we received from CableLabs
MSOs on how to address the Sig MIB NCS SF related mib objects and in the
meantime, we also received input from ETSI. Apologies for the delay.

   In brief, the CableLabs MSO operators' feedback was:
   a) Deprecate MTA Sig MIB objects to set up NCS Service Flows via MTA
config file. The preferred mechanism for establishing DOCSIS Service
Flows for the MTA NCS traffic is via the CM config file. While some
operators like having the choice and the option to do this in the MTA,
practically, most are using the CM config file today and they have no
plans to migrate to using the MTA Sig MIB for that, hence the decision
to deprecate those objects. (Note that "deprecate" is to be read here in
the context of the MTA Sig MIB currently defined under CableLabs; for
the IETF IPCDN Signaling MIB ID, this means CableLabs' members are in
favor of object deletions).

   b) CableLabs should add new CMTS requirements to mitigate the
potential security risks related to DOCSIS Service Class Name
provisioning and Service Class Name policy authorizations. A PacketCable
DQoS Engineering Change has been opened. This addresses some of the
concerns some of you raised on the IPCDN list as well.

Therefore, based on the comments received on the IETF IPCDN list from
Wim De Ketelaere, David De Reu, Rich Woundy, Gordon Beacham, Thomas
Anders of Blue Cable and many others, the input from ETSI via the recent
liaison statement and the above input from operators members of
CableLabs, I believe we have reached IPCDN wg consensus to delete the
following MIB objects from the IPCDN MTA Sig MIB ID:
pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, and
pktcSigServiceClassNameMask objects.

Any objections?
Jean-Francois.