Subject: Re: [Megaco] New Draft on Legal Intercept in MEGACO without useof Topology descriptor

From: [email-masked]
Date: Mon, 23 Dec 2002 17:44:09 +0530

Hi Christian,

please see our comments below [HSS].

regards
Rohit Gupta
Vivek Bansal

Christian Groves <[email-masked]> on 12/18/2002 10:52:27 AM

To:   Vivek Bansal/HSS@HSS
cc:   Terry L Anderson <[email-masked]>, Kevin Boyle
      <[email-masked]>, Rohit Gupta/HSS@HSS, [email-masked]

Subject:  Re: [Megaco] New Draft on Legal Intercept in MEGACO without useof
      Topology descriptor

Hello Vivek and Rohit,

Please see my comments below.

>From past discussions also on this topic I was under the impression that the
IETF did not support mechanisms solely designed for the purposes of Legal
Interception.

Regards, Christian

[email-masked] wrote:
>
> Hi Kevin/Terry/Christian
>
> Thanks for your comments. Before writing this draft we were fully aware that
> whatever can be achieved
> with this package can be very well done by the topology descriptor also.
However
> we still decided
> to write this package for the following reasons
>
>
>   2. This scheme will work in conjunction with topology descriptor also.
Imagine
> a scenario where you could have a three
>        party call with all of the parties under intercept (very imaginary
> scenario though). You could have the conference setup
>       using the topology while the intercept takes place at terminations.
Using
> topology alone for this can get very complex
>       and would require 6 terminations to be added to the context.

[CHG] I don't understand. The premise for this package is that you don't have
the topology descriptor?? If you have the topology descriptor then you don't
need the package.

[HSS] This example was just to show that this mechanism can very well co-exist
with topology descriptor. The topology is used to handle multi-party scenarios
like call waiting and three way calling, while the intercept mechanism can
continue to be package based. If only topology is used, then there may be
six terminations in a context, something which may be limited by the gateway
implementations and hence their capability to support this scenario.

>
> 3. Implementors have always found Topology as the complex feature of the
> protocol to implement.
>     There are forums (like MSF) which have not mandated the use of Topology
> descriptors and yet looking for
>     mechanism to provide support for Legal Intercept. Combining Legal
Intercept
> with Topology
>     would mean forcing the gateway implementations to support topology. This
> package provides a
>     very simple (as the rules for media replication according to the package
are
> very simple) mechanism
>     to intercept media and transport it towards intercept authority. We have
> deliberately not specified
>     the format of intercepted streams or how these are setup since these could
> be specific to the
>    network scenario/country etc and are best left open.

[CHG] As discussed by Kevin earlier the hardware and connection setup on the MG
would be identical for each case so I don't see that you save much.

[HSS] The connection setup would be same for both schemes. It is the complexity
of processing the topology descriptor and its impact on the rest of the protocol
(specially in scenarios like three way calling with all parties under intercept)
that we are talking about. With the scheme that we have proposed, the processing
rules (and thus implementations) remain simple.

>
> 4  There are gateways in the network architecture which do not require
complete
> topology support
>       and still needs to support LI. Therefore this package will provide them
an
> alternative way.

[CHG] If the MGC tries to set a topology that the MG doesn't support then the MG
can always provide an appropriate error code.

[HSS] The idea is to implement intercept capability without going into topology
processing rules.

>
> Best Regards,
>   Rohit Gupta
>   Vivek Bansal
>
> Christian Groves <[email-masked]> on 12/16/2002 06:21:39 AM
>
> To:   Terry L Anderson <[email-masked]>
> cc:   Kevin Boyle <[email-masked]>, Rohit Gupta/HSS@HSS,
>       [email-masked] (bcc: Vivek Bansal/HSS)
>
> Subject:  Re: [Megaco] New Draft on Legal Intercept in MEGACO without use of
>       Topology descriptor
>
> G'Day,
>
> I think Kevin and Terry comments highlight the problems with this draft very
> well. Apart from the duplication of functionality arguments I think this is
also
> going against the Megaco connection model. With the addition of this package
we
> would have another stream of data that does fit use the context, termination
and
> stream model. Thus if people want to do LI then they should use topology.
>
> Regards, Christian
>
> Terry L Anderson wrote:
> >
> > I agree with Kevin.  There is no more likelihood that this package will
> > be implemented on a given element than the topology descriptor and
> > probably less.  The only reason for a second way to do this would be if
> > its implementation were much easier than the full topology package.  But
> > this does not appear to be the case.  It is far preferable to implement
> > the more general package and bad to have two ways to do the same thing.
> >
> > Kevin Boyle wrote:
> >
> > >I do not see the utility of this package, other than making an optional
> > >descriptor into an optional set of properties.  The streams will still have
> > >to be forked, so the real underlying packet forking work will still have to
> > >be done.  If the function of the topology descriptor is needed, then why
not
> > >implement it?
> > >
> > >This seems to be attempting to solve a problem that doesn't exist.  The
main
> > >(stated) motivation here is that the topology descriptor is optional.
> > >Packages are ALSO optional, so this does not solve the stated problem.
> > >Also, the lack of information on how to set up the replicated streams to
the
> > >LI receiver is a big weakness of this draft.  While much of that will be up
> > >to the individual implementation, the lack of even a mention on how it
> > >would/could be done indicates that this is a problem that hasn't received
> > >much thought.  I believe that it will involve at least the same work as
> > >implementing the topology descriptor, meaning that this really isn't as
> > >simple as just defining a package.
> > >
> > >The topology descriptor was invented for exactly this kind of application.
> > >Just because it is optional doesn't mean you CAN'T use it.  If the H.248
> > >elements require the use of that function (because, for instance, LI is
> > >required by law) then the descriptor should be implemented.  This draft
> > >attempts to reinvent the topology descriptor, without going through the
> > >exercise of defining termination and stream interactions within the
context.
> > >The interactions between the forked streams and the rest of the context
> > >should be explained and well defined.  The topology descriptor and its
> > >effects upon the terms and context are rigorously defined and well
> > >documented.
> > >
> > >I suggest that we not reinvent the wheel.  The topology descriptor is
> > >capable of producing the required results, is well defined in its
> > >interactions with the definitions and elements of the rest of the H.248.1
> > >specification, and is an already existing portion of the base H.248.1
> > >specification, whether it is optional or not.  This draft defines a package
> > >that is not capable of producing the required results without additional
> > >specification, is not well defined in its interactions with the rest of the
> > >specification, and has the additional weakness of being an add-on, rather
> > >than an integral part of the specification.
> > >
> > >Kevin
> > >
> > >-----Original Message-----
> > >From: [email-masked] [mailto:[email-masked]]
> > >Sent: Thursday, December 12, 2002 9:46 AM
> > >To: [email-masked]
> > >Subject: [Megaco] New Draft on Legal Intercept in MEGACO without use of
> > >Topology descriptor
> > >
> > >
> > >
> > >
> > >
> > >A New Internet-Draft is available from the on-line Internet-Drafts
> > >directories.
> > >
> > >
> > >        Title           : Legal Intercept Package for Megaco/H.248
> > >        Author(s)       : R. Gupta, V. Bansal
> > >        Filename        : draft-rogupta-hss-megaco-legal-intercept-00.txt
> > >        Pages           : 13
> > >        Date            : 2002-12-11
> > >
> > >This document proposes a mechanism for MEGACO controlled legal intercept
> > >without the use of topology descriptor. Only call content duplication is
> > >addressed in this draft. The generation of call data information is outside
> > >the scope of this draft.
> > >
> > >A URL for this Internet-Draft is:
> >
>http://www.ietf.org/internet-drafts/draft-rogupta-hss-megaco-legal-intercept
> > >-00.txt
> > >
> > >
> > >
> > >DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
> > >(HSS) and is intended solely for the use of the individual to whom it is
> > >addressed. It may contain  privileged or confidential information  and
> > >should not be circulated or used for any purpose other than for what it is
> > >intended. If you have received this message in error, please notify the
> > >originator immediately. If you are not the intended recipient, you are
> > >notified that you are strictly prohibited from using, copying, altering, or
> > >disclosing the contents of this message. HSS accepts no responsibility for
> > >loss or damage arising from the use of the information transmitted by this
> > >email including damage from virus.
> > >
> > >
> > >_______________________________________________
> > >Megaco mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/megaco
> > >_______________________________________________
> > >Megaco mailing list
> > >[email-masked]
> > >https://www1.ietf.org/mailman/listinfo/megaco
> > >
> > >
> > >
> >
> > --
> > -------------------------------------------------------
> > Terry L Anderson                     [email-masked]
> > Voice: +1 908.766.4463          Mobile: +1 908.342.9595
> > http://www.gti.net/tla
> > -------------------------------------------------------
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: [email-masked]
Date: Mon, 23 Dec 2002 17:44:09 +0530

Hi Christian,

regards
Rohit Gupta
Vivek Bansal

To:   Vivek Bansal/HSS@HSS

Hello Vivek and Rohit,

Regards, Christian

However
Imagine
Using

Intercept
are

complete
an

also
we
and
not
main
the
context.

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 27 Dec 2002 02:42:10 -0500

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, December 23, 2002 7:14 AM
To: Christian Groves
Cc: Terry L Anderson; Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked];
[email-masked]

Hi Christian,

regards
Rohit Gupta
Vivek Bansal

Christian Groves <[email-masked]> on 12/18/2002 10:52:27
AM

To:   Vivek Bansal/HSS@HSS

Hello Vivek and Rohit,

Regards, Christian

[email-masked] wrote:
>
> Hi Kevin/Terry/Christian
>
> Thanks for your comments. Before writing this draft we were fully 
> aware that whatever can be achieved with this package can be very well 
> done by the topology descriptor also.
However
Imagine
>        party call with all of the parties under intercept (very 
> imaginary scenario though). You could have the conference setup
Using
>       and would require 6 terminations to be added to the context.

[CHG] I don't understand. The premise for this package is that you don't
have the topology descriptor?? If you have the topology descriptor then you
don't need the package.

[HSS] This example was just to show that this mechanism can very well
co-exist with topology descriptor. The topology is used to handle
multi-party scenarios like call waiting and three way calling, while the
intercept mechanism can continue to be package based. If only topology is
used, then there may be six terminations in a context, something which may
be limited by the gateway implementations and hence their capability to
support this scenario.

[KJBII] Generally speaking, Lawful Intercept is directed at an individual,
not a conference.  (Your local laws may vary.)  Inserting the LI listener
between the observed party and the conference seems to me to be a better
solution, if you are worried about complexity.  Again, if a gateway cannot
support what is required of it, then it is useless.  The evaluation of what
is required of a particular MG will come from the customer who will buy it,
and translated into requirements for implementation.  If a customer wants an
MG that can do 3WC and LI, then I would assume that the MG will have to
handle a scenario where both are involved.  If the MG cannot handle this
scenario, then it doesn't meet the requirements.

>
> 3. Implementors have always found Topology as the complex feature of 
> the protocol to implement.
>     There are forums (like MSF) which have not mandated the use of 
> Topology descriptors and yet looking for
Intercept
> with Topology
>     would mean forcing the gateway implementations to support 
> topology. This package provides a
are
> very simple) mechanism
>     to intercept media and transport it towards intercept authority. 
> We have deliberately not specified
>     the format of intercepted streams or how these are setup since 
> these could be specific to the

[CHG] As discussed by Kevin earlier the hardware and connection setup on the
MG would be identical for each case so I don't see that you save much.

[HSS] The connection setup would be same for both schemes. It is the
complexity of processing the topology descriptor and its impact on the rest
of the protocol (specially in scenarios like three way calling with all
parties under intercept) that we are talking about. With the scheme that we
have proposed, the processing rules (and thus implementations) remain
simple.

[KJBII]  I believe that the topology descriptor is amazingly NON-complex for
what it conveys.  Further, I debate that what you have proposed is simple.
In many ways, due to the lack of specification on HOW the interconnect of
the replicated streams will affect the rest of the context, your proposal is
MORE complex than the well-integrated TP descriptor.

I'm going to jump up on a soapbox for a moment.  It seems to me that there
has been a stigma attached to the Topology descriptor, and this seems to
stem from the fact that it has been made optional in the specification.  I
believe this to be ill-deserved, because the TP descriptor is, in fact,
remarkably elegant and efficient.  Further, the TP descriptor allows easy
control of newly added terminations even before they are added to the
context -- something that this proposal doesn't allow.  I have never heard
any argument against the TP descriptor, other than "It's complex."  Well,
the idea of controlling interconnect among many parties is complex, and it
makes sense that the function described by the TP descriptor would be the
same.  Even so, the TP descriptor itself provides a concise description of
that complexity -- one that is easily followed, reducing the complexity to
the interconnect function itself, instead of the function AND its
description.

This proposal extends that complexity to the description of the interconnect
function as well.  This is, I believe, a huge mistake.  The TP descriptor,
at any moment, describes the entire interconnect of the entire context.  By
scattering this information over the LC descriptors of each termination, you
increase the difficulty of seeing the "big picture".  Besides, termination
interconnect is a CONTEXT function, and as such, belongs on the context.
This proposal would strip that away, and make it a termination function.

complete
an
> alternative way.

[CHG] If the MGC tries to set a topology that the MG doesn't support then
the MG can always provide an appropriate error code.

[HSS] The idea is to implement intercept capability without going into
topology processing rules.

[KJBII] I will state again one of the premises of my argument, that has been
ignored by this proposal:  Even though the spec says the TP descriptor is
optional, that doesn't mean that it isn't required for the APPLICATION the
MG will fulfill.  If the TP descriptor is required to fulfill the
obligations that the customer places upon the MG they purchase, then it's
REQUIRED.  It's as simple as that.  If you cannot find another pre-defined
solution within the protocol, then the obvious choice is to implement the
"optional" portion that is designed for exactly this scenario.  Don't
reinvent the pieces of the protocol that you don't like or find difficult.
If you don't find it valuable, then attend the standards meetings and work
to have it removed from the standard.  Otherwise, don't invent new ways that
are even LESS interoperable than the TP descriptor.  At least all the
existing H.248 implementations are aware of the TP descriptor and have made
a conscious choice whether or not to support it.  Adding a package to do the
same job will be a disaster, because there will always be those that have no
idea it exists.

>   Vivek Bansal

[SNIP!!]

---

From: "Kevin Boyle" <[email-masked]>
Date: Fri, 27 Dec 2002 02:42:10 -0500

Comments inline. [KJBII]

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, December 23, 2002 7:14 AM
To: Christian Groves
Cc: Terry L Anderson; Boyle, Kevin [NCRTP:3R90:EXCH]; [email-masked];
[email-masked]

Hi Christian,

regards
Rohit Gupta
Vivek Bansal

To:   Vivek Bansal/HSS@HSS

Hello Vivek and Rohit,

Regards, Christian

However
Imagine
Using

Intercept
are

complete
an

[SNIP!!]