Subject: Re: Topology

From: "Alessandro Mordacci (ERA)" <[email-masked]>
Date: Thu, 26 Aug 1999 16:09:37 +0200

Brian (and others), please also find my comments below marked with [ALE]

        >To implement LI, you need all the components of the network to do the
        >right thing.  What is the right thing for Megaco, which is in the middle?
        >Doesn't it depend on what the MGC does?  Does it have anything to do with
        >how the MGC-MGC protocol works?
        [ALE] You need interception in the MGC (for the signalling) and in the MG (for the media).
        The ETSI standard (which is expected to be required in all the EU sooner or later) explicitly forbid to use the signaling protocol to request any information only for the purpose of LI. It makes sense. The LEA should only know what is available in the node who performs the interception. So the protocol between the two MGCs does not matter.

        >What about the edge router - if it is
        >a REQUIREMENT that data taps be made, then it may make much more sense
        >to do all the intercept there.
        [ALE] In my view, the network routers are pure transport. If there is interception in the router, I need a protocol to turn it on and off at specific times (i.e. hold). The knowledge is only in the MGC. I do not like to couple the MGC and a router. Besides I see obvious problems in cutting on and off the subscriber on hold and the interception in two different nodes at the same time. I may agree with you that in the future there may be a requirement to intercept IP or ATM traffic as such. We could prefer to have the same kind of equipment doing all the interception. That does not means it will be possible.

        >You can't decide what the requirements in the MEGACO protocol are without
        >understanding what the system requirements are, and allocate them
        >appropriately.
        [ALE] I did not partecipate in setting the requirements for megaco. When I starting looking at the protocol, the "wiretap" was in the requirements and it seemed quite obvious to me why. Being an European, I cannot do anything about CALEA but to comply if I want to sell a piece of equipment in the US, and, honestly, I think it's fine. If I read CALEA, it think to understand those requirements. And, I think they have decided the allocation of functionality. Same thing for ETSI. I know how to implement them, the only missing piece is something like the topology.

        >You can't meet the deadline by making MEGACO do all the
        >work.  You can't meet the deadline if MEGACO makes one assumption, and
        >edge routers make another that conflict.  I wouldn't even start working
        >on implementations of this kind of capability unless I got the LEAs to
        >look at the whole SYSTEM and tell me if it meets the requirements because it
        >is harder to fix it AFTER I commit a design.
        [ALE] You have a law. Can you ask a judge if what you do is legal before you do it? No, you can only consult a lawyer and hope that his suggestion will be correct. I suspect this will be the same.

        >This effort smacks of
        >"Do something, do anything, the sky is falling".

        >There is NO way you can claim that the topology solution offered is
        >necessary or sufficient to achieve the goal.  You can only claim that
        >you think it might be looking at the problem through blinders.
        >That is not good enough.

        >Doing a proper system design is not only practical, it is necessary.
        >We can only argue about who does it.  It can be done if all the components
        >and the interfaces are standardized, or it can be done proprietarily.
        >There is sufficient time to do it right.  There has to be sufficient
        >motivation, we should participate (we HAVE to participate), but we can't
        >do it alone.
        [ALE] There are always implementation choices that are left to the engineers... a car is a very clear standard: neverthless we have quite a lot of different types of cars. There are applications where CALEA and ETSI define function allocation and interfaces. I would like to be able to implement them (for those applications). The kind of security mechanisms in the network, I believe this is an implementation choice.

>With respect to context parameters, when we need them, we add them.
> We have been discussing what makes the most sense in this case.
> I happen to agree that making it a command parameter is easier in this
> case, regardless of whether it is done with pairwise specification
> or list per termination.

[CHG] I'm not sure I understand here. Do you then agree that we can make
a termID optional in a command?

>
> I will take issue with parameters being optional.  Packages are optional
> commands, and their parameters are not.  We aren't protocol police,
> but if we defined topology, ANY Megaco/H.248 implementation would have
> to implement them if it was claimed to be conformant to the spec.

[CHG] OK I made a mistake with terminology here. I meant to say that
this is a 'property' of a context. Properties are definately optional.
ie. not all MGs will be able to support GSM. To me a package was saying
that you support a set of properties.