RE: Re: IETF IPCDN Signaling MIB - Draft 3 - Last Call for Comments

David,
	I'm not certain I agree with your statement that: "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."  While I would agree that there is no defined
mechanism for a plain modem to initiate a DSx message, I do not believe
that it is prohibited.  While console access is prohibited, SNMP access
is not (both via the RFI and the CMCI, unless administratively
prohibited), which means that it could be controlled for example via a
proprietary MIB.

Matt

-----Original Message-----
From: David De Reu [mailto:[email protected]] 
Sent: Monday, January 19, 2004 8:54 AM
To: IPCDN Mailing List
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?



(2) pktcSigDevRtCadence is superfluous

   The pktcSigDevRtCadence object is not needed, and introduces an
   ambiguity in the MIB. First of all, this object is intended to
   specify the "ring cadence rt", but "rt" is not really a ring cadence:
   it is the ringback tone. The "rt" signal does not cause ringing
   voltage to be applied to the analog line, but causes a *tone* to be
   played to the calling party. Indeed, the ringback tone is included in
   the pktcSigDevToneTable. Like for every tone, the MTA will consult
   this table to determine the properties of the ringback tone, and
   hence the pktcSigDevRtCadence object will not be used anyway.

   Solution: we suggest the removal of the pktcSigDevRtCadence object.



(3) pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence

   There needs to be clarification on the difference between these
   objects and the pktcSigDevRgCadence and pktcSigDevRsCadence. Agreed
   that the latter is for North American systems, and the former is for
   international systems, but it must unambiguously be clear to an MTA
   vendor when to use which object.

   Is it correct to state that an MTA for the international market would
   have to implement both alternatives according to the module
   compliance statement, but it would only use the international pair of
   objects? If this is the case, then why require that the North
   American pair of objects has to be implemented?



(4) pktcSigPulseSignalTable, pktcDevRingCadenceTable and E-package

   Regardless of any changes to the table definitions, we suggest to
   make it clear that they only need to be implemented when the ETSI
   E-package is supported. Without support for the E-package, these
   tables have no use.

   By the way, can the operator currently determine by MIBs which
   NCS packages the MTA supports (and in particular, if the MTA supports
   the E-package)?



(5) Mapping NCS signal requests (tones, rings) to MIB objects

   How will an MTA vendor currently know unambiguously when to use
   which tone or ring cadence definition for a given NCS signal request?



(6) pktcSigDevSilenceSuppression: per codec is better

   It was argued before that on one hand VAD is independent of the
   codec, but on the other hand in practice different VAD
   implementations may be needed for different codecs, and hence the
   presence of such a VAD implementation depends on the codec (so that
   for instance VAD would be supported for G.729 but not for G.711).

   As far as I can see, it is indeed logical to let VAD support depend
   on the codec, since the exact algorithm used for VAD may be different
   for different codecs. This is apparently also the viewpoint taken in
   the PacketCable NCS specification [PKT-SP-EC-MGCP-I08-030728, p.35],
   where we read in the context of an MTA's capabilities (that can be
   queried by an AUEP command): "If there is a need to specify that some
   parameters, such as e.g., silence suppression, are only compatible
   with some codecs, then the gateway will return several capability
   sets". Note that only the CMS can normally send an AUEP that queries
   the MTA for its capabilities, and not the SNMP manager. Therefore,
   the same functionality must also be provided by the MIB.

   In contrast with the NCS spec, the PacketCable PROV spec considers
   VAD independent from the codec (MTA capabilities TLV 5.12). This may
   be a reason to also do it this way in the MIB, but according to the
   arguments above this is not the best thing to do. Therefore we feel
   it is better to adopt a more correct MIB definition instead, i.e.
   letting the support of VAD depend on the codec.



Thanks,

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 _____________________________________________________




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