RE: IETF NCS Sig MIB draft 6 -> Issue withEpackagerequirements

Hi David,

Thanks for the very helpful background and the suggestions.

Randy,
Appreciate your expertise and aid in keeping us accurate and
unambiguous.


I took suggestion-1 since Euro-PacketCable is well-defined
and suits our needs. I did however use the phrase 
'only for Euro-PacketCable' - avoiding the confusion introduced
earlier by the term 'only'!:) (Thanks for the catch Randy!)


Version-7 of the draft should be submitted shortly...


regards
Sumanth

-----Original Message-----
From: David De Reu [mailto:[email protected]] 
Sent: Friday, October 22, 2004 1:16 AM
To: Sumanth Channabasappa; [email protected]
Cc: Kristof Sercu
Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue
withEpackagerequirements 


> How about we change the objects mentioned specifically as being 
> required for 'L Package only'?
>
> David?

I think this is different from the original intention.


Background
==========

The intention, to my belief, was to define these objects because they
are needed for MTA's for the "international market" only (i.e. Europe in
practice). These MTA's would have to be able to comply with the relevant
ETSI specs. The MIB objects define different timing values regarding CID
(Caller ID transmission) and VMWI (Visual Message Waiting Indicator) as
defined in the ETSI specs. The timing values can be different per
country or operator in Europe, but apparently don't apply to North
America.

Of course both CID and VMWI exist in North America as well. CID and VMWI
are triggered by elements of the "L package" (which is always
implemented by all MTA's). The only difference is that MTA's for the
"international market" would have to take the MIB objects into account
as well, whereas the "North American" MTA's would not.

The "E package" is something that only applies to ETSI systems, but is
in practice not always implemented (as opposed to the L package).
Therefore, in practice the terms "ETSI systems" and "E package" are NOT
equivalent. I am aware that one or some of my e-mails in the thread
"Signaling MIB - Draft 3 - Last Call - Clarification US/intl.
requirements" may have suggested otherwise, but these are the practical
limitations we have to consider. By the way, the E package has nothing
to do with the MIB objects at hand.


Additional question
===================

Are there no timers at all with respect to CID and VMWI in North
Amercia? Or are the timers in North America standardized, and can they
be expressed in terms of the MIB objects under discussion?


Suggestion
==========

(1) assuming that the MIB objects indeed do not make sense in North
America:

Referencing the L package as in "L package only" (with or without the
"only"
part) would make the MIB objects mandatory to implement for North
American (i.e. pure PacketCable) MTA's as well, which apparently doesn't
make sense since they do not apply there (remember, they are
translations to the MIB of timers defined in the ETSI specs).

The discussion is a bit analoguous to the recent
pktcSigPowerRingFrequency issue raised (where you want a different
default for North America vs. Europe). In other words, you would have to
find some wording that makes this clear, without referencing either the
L package or E package. If "international" is not good enough, maybe we
can revert to  the term "ETSI systems" as was once used? Alternatively,
we can distinguish between PacketCable and Euro-PacketCable  instead of
North American and International, like e.g. in the IPCDN docsIfMib where
there is a distinction between DOCSIS and Euro-DOCSIS (spelled
"EuroDOCSIS", in
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt)
.

An MTA would be an "ETSI system" or not, depending on its intended
usage, i.e. the market it is meant for.

(2) assuming that the North American timer values can be expressed in
terms of the ETSI MIB objects:

In this case it may make sense to make the MIB objects mandatory for all
MTA's, which solves the problem very easily: no extra reference to L
package, E package or ETSI systems would be necessary anymore.



Hope this helps a bit,

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 _____________________________________________________