RE: IETF IPCDN Signaling MIB - Draft 3 - Last Callfor Comments [NEW ISSUE Caller ID Ranges]

> I recommend leaving the range for these objects as 0, as
> presently defined in the MIB and indicating that the object range
> meets or exceeds the ranges in the 300 659 specification.

That would imply that it is possible to configure, by MIB, the MTA to be
non-ETSI compliant. Is there a specific reason for this? For instance, do
you have knowledge of large numbers of rolled-out equipment (e.g. caller ID
devices) that are non-ETSI compliant, and thus require different timing
constraints? Or do you want a lower bound of zero to accomodate for future
changes in the ETSI specs?

> The
> later specification should be the definitive guide for any
> pass/fail test criteria.

The ETSI specs would indeed be the basis for the test criteria. For example,
for the pktcSigDevCIDRingAfterFSK value, the 300 659 spec says the minimum
is 200 ms. Assuming that the range in the MIB allows for values outside the
ETSI range, then how do we interpret this?
We feel that, for testing purposes, the MTA MUST implement at least the ETSI
range. Values outside the ETSI range, but inside the MIB range, would then
have to return an SNMP "Commit failed" error on a SET for such a value. This
would then be tested. Second, values outside of the MIB range would return a
different error, "Bad value", which is of course also tested. This means
that, depending on the value SET, the error message would be different.

However, we also feel that, apart from adding a little complexity to the
MTA, a MIB range that differs from the ETSI range possibly confuses the
users of the MIB, i.e. the operators. So why not use the ETSI range as the
MIB range?

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
_____________________________________________________