RE: Re: IETF IPCDN Signaling MIB - Draft 3 - Last Call fo r Comments [item 1]

David,

regarding item (1):

>Solution: It is of course not up to the SIG MIB to provide a solution
   to this problem. 

You raise some good discussion points. Unfortunately, this is not an issue for the NCS Signaling MIB to resolve.

Instead I would recommend specification concerns be raised on the DOCSIS reflector and via the ECN process as necessary.

>snip

From: "David De Reu" <[email protected]>
To: "IPCDN Mailing List" <[email protected]>
Date: Mon, 19 Jan 2004 16:53:32 +0100
Subject: [ipcdn] Re: IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments

Dear all,

Below I have listed some items for discussion based upon trouble points
we found with draft-02. I think it would be beneficial if we could get
these sorted out before draft-03, because it would greatly reduce the
number of ambiguities, thus making it more clear for an MTA vendor how
to implement the MIB.



(1) pktcSigServiceClassName(US|DS|Mask) objects

   There is still a problem with the pktcSigServiceClassName(US|DS|Mask)
   objects (and indirectly with the related pktcSigNcsServiceFlowState
   object). Although the MIBs currently reflect the PacketCable PROV
   spec text, the proposed system for setting up a signaling service
   flow will *NOT* work with a PacketCable/IPCablecom compliant CMTS.
   This is because the CMTS must reject all DSx messaging initiated by
   the CM if there is no valid authorization block. There is no such
   block in this case (there even is no gate on the CMTS). Note that
   this does not mean that PacketCable takes a step backward compared to
   (Euro-)DOCSIS. In plain (Euro-)DOCSIS it is the case that a CM is not
   allowed to initiate DSx messaging, since it is not allowed to expose
   an interface to the outside world to do this. For an embedded MTA in
   PacketCable, this interface is present and the DSx messaging *can* be
   initiated by the CM, but the CMTS will accept it only if the
   appropriate authorization can take place (using the authorization
   block).

   Operationally, the practical solution is quite simple. You can add
   the necessary MIB objects in the CM config file (specifying the
   service flow parameters directly, or alternatively using a Service
   Class Name (SCN)). In that case, the CM will set up the service flow
   during its registration, without the need for DSx messaging.

   Solution: It is of course not up to the SIG MIB to provide a solution
   to this problem. However, if the pktcSigServiceClassName(US|DS|Mask)
   objects *are* included in the MIB, then you have a set of objects of
   which you know on forehand that they are useless. So the question
   seems to me: do we want to include these objects in the MIB? We could
   also leave them out now, and wait for a correctly functioning
   mechanism to be defined in the PacketCable/IPCablecom specs.
   Alternatively, if the objects remain in the MIB, then we have to ask
   ourselves what will be required from an MTA: we will require that the
   MTA does the DSA nevertheless, knowing that it will not succeed
   anyway?

>>>>snip