Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 29 Apr 2004 15:02:13 -0600

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-masked]] 
> Sent: Thursday, April 22, 2004 6:52 AM
> To: [email-masked]
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "David De Reu" <[email-masked]>
Date: Fri, 30 Apr 2004 09:53:18 +0200

Dear all,

The summary list composed by Jean-Francois looks complete to us.

We are willing to provide further input at any time.

Regards,

David

_____________________________________________________
David De Reu
tComLabs
Stapelplein 70/004 – 9000 Ghent – Belgium
Tel: +32 9 269 22 91 – Fax: +32 9 329 31 74
www.tComLabs.com
_____________________________________________________

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Jean-Francois Mule
> Sent: donderdag 29 april 2004 23:02
> To: Thomas Anders; [email-masked]
> Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects
>
>
> 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.
>
> 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?
>
> 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?
>