RE: RE: NCS Signaling MIB SC Objects
"Jean-Francois Mule" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Hi Thomas & all, I would like to summarize the list of open issues first. Once we agree that this is the list of issues we need to address, and reach consensus on how to solve it, we can figure out the best way to get it done. Here's a summary of the key issues raised by wg participants, please review & comment. 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? 2/ Are the DOCSIS Service Class Name provisioning on the CMTS (and all the associated policies to authorize flows based on SCN and other rules) too open to vendor differentiation, hence opening up security risks? 3/ Should we clarify any specs and if yes, to specify what and where? Should some informative text be added on the Service Class operations for NCS Signaling & mandate that "some kind of" configuration parameters be provided to set up authorization policies. Should this be in the DOCSIS RFI 2.0 SP-RFIv2.0-I04-030730 Section 10.1.3 Service Classes p 207? Does this belong to DQoS? Shoud some normative requirements be added on the E-MTA to define what operations the MTA needs to perform upon setting those MIB objects? 4/ Should we allow an MTA to support multiple Service Class Names simultaneously and define a more complex NCS SF MIB table to allow per CMS configuration? Did I miss or mistate anything? Jean-François > -----Original Message----- > From: Thomas Anders [mailto:[email protected]] > Sent: Thursday, April 22, 2004 6:52 AM > To: [email protected] > Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects > > > Hi all, > > AFAICS most people seem to agree here that the dQoS specs > should be changed if one wants these SC objects in the SIG-MIB. > > How to proceed? Anyone willing to write up an ECR (and, > preferrably, Cc: to this list)? > > > Best regards, > Thomas > > -- > Thomas Anders (thomas.anders at blue-cable.de) > > _______________________________________________ > IPCDN mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ipcdn > >