Subject: Re: Topology

From: "Alessandro Mordacci (ERA)" <[email-masked]>
Date: Thu, 26 Aug 1999 10:43:46 +0200

A complete model for LI looks like to stretch a bit too much the charter. I think that we should just put all the elements that allow interception where it makes sense. If there would be only one possible type of MG than I would understand the need of a complete model. Hopefully, we will see quite a lot of different kinds of MGs, and interoperation will not be as simple as swapping boxes anyway. At the same time, if I can change the topology, I do not see any reason why interception cannot be implemented in a big trunking gateway, using only standard features. I can understand that someone is only interested in small residential gateways. But, if we need to have a common protocol, then we need to satisfy the requirements for all the applications. Even if we will have a complete model in the future, we will still have this topology requirement. Why not to put it in the protocol now?

As someone said in this list (I remember something about ETSI), other institutions are working on a global model of lawful interception. If the IETF wants to join that, personally, I'm not against. I do see a lot of difficulty, but this is another matter. Statistically, some of us should work in free countries, so they should have the right to care about these problems :-).

However, I think that it will be really too much a work for megaco alone, given the very broad scope. IMHO we should limit ourselves to incorporate the requirements that we do have on the control protocol.

Cheers,

Alessandro

> -----Original Message-----
> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Thursday, August 26, 1999 1:40 AM
> To:   [email-masked]
> Subject:      Re: Topology
>
> I believe it is in the LEAs' best interest to make this possible.
> If we are dealing with people of the caliber of the FBI/NSA, they
> are not stupid, quite the contrary.  I believe they will
> work with us to make such an approach work, because it is
> clearly in everyone's interest to do so.
>
> I think that we can make the deadlines, but we have to put effort
> into doing so.  The effort we are spending arguing about one
> piece of the puzzle without considering the other pieces would
> be much better spent working on a systematic approach that
> meets the requirements, in the time frame.
>
> I further posit that if, in fact, ITU and IETF are actively
> cooperating with the LEAs, and rapid progress is apparent,
> that it is conceivable that time frames will be adjusted to
> deal with reality.  This may or may not be an issue which
> is settled by common sense however, so I wouldn't care to bet
> on it.
>
> Brian
>
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Wednesday, August 25, 1999 7:02 PM
> > To: Brian Rosen
> > Cc: [email-masked]
> > Subject: Re: Topology
> >
> >
> > Brian,
> >
> > Brian Rosen wrote:
> > > I suggest:
> > >         Wiretap be deferred to Version 2
> >
> > Would Version 2 be available some 3 to 6 months before July 2000?
> > In other words, by January?
> >
> > >         The IESG and the ITU get together a group
> > >                 to do the system design.  This needs to
> > >                 include:
> > >                         From IETF:
> > >                                 MEGACO
> > >                                 MMUSIC
> > >                                 IPTEL
> > >                                 ?Security?
> > >                                 ???? Others
> > >                         From ITU
> > >                                 SG16
> > >                                 SG11
> > >                                 ???? Others
> > >         When the system design is complete, the various groups
> > >                 need to hammer out implementations
> >
> > There may be some difficulties with this as regards IETF.
> > Documentation
> > is quite restricted due to the reluctance of LEAs to discuss their>
> > equipment, methods and procedures in public forums.  Security
> > clearances
> > are normally required.
> >
> > --
> > Brian F. G. Bidulock
> > Associate Director - New Products
> > Inet Technologies Inc.
> > 972-578-3959
> >