Subject: [Sipping] FW: I-D ACTION:draft-sriram-sipping-poc-lip-01.txt

From: [email-masked]
Date: Mon, 22 Aug 2005 15:40:22 -0500

I would be interested

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 2:50 PM
To: [email-masked]
Subject: I-D ACTION:draft-sriram-sipping-poc-lip-01.txt 

This walled garden proposal makes me wonder why the authors do not mention
RFC 3925 in the references, see

 ftp://ftp.rfc-editor.org/in-notes/rfc3924.txt 

Also, a discussion of why this proposal is better than RFC 3925 would be
quite interesting to add.

Last but not least, what if the bad guys do not use voice to communicate?

Thanks, Henry

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Lawful Intercept procedure via the Session
                          Initiation Protocol (SIP) for the Open Mobile 
                          Alliance (OMA) Push to talk over Cellular (PoC)
	Author(s)	: S. Sriram
	Filename	: draft-sriram-sipping-poc-lip-01.txt
	Pages		: 13
	Date		: 2005-8-22
	
This document describes the Lawful Intercept Procedure using Session 
   Initiation Protocol (SIP) used by the Open Mobile Alliance (OMA), for 
   Push to talk over Cellular (PoC) along with their applicability, which 
   is limited to the OMA PoC application.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sriram-sipping-poc-lip-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sriram-sipping-poc-lip-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-sriram-sipping-poc-lip-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 23 Aug 2005 08:33:02 +0300

>                           Alliance (OMA) Push to talk over Cellular

why is Push to talk over Cellular protocol needed at all?  why should it
matter if push to talk sip UAs are connected to cellular network rather
than anywhere on the internet?  ietf mailing list bandwidth should not
be consumed for these kind of walled garden problems.

-- juha

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 23 Aug 2005 08:40:33 -0500

Juha raises a valid point, besides the CALEA issues raised before:

Push-to-talk is a normal function of any SIPMPLE compliant SIP UA and needs
no separate RFC. My current SIP UAs that have push-to-talk (click on buddy)
include soft phones like the XTEN eyeBeam or the snom360 desktop phone.

OMA would be best advised just implementing the SIP/SIMPLE standards 'as is'
IMHO.

It sure would be of general interest to find out of some existing SIP/SIMPLE
standards work has overlooked anything...

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Juha Heinanen
Sent: Tuesday, August 23, 2005 12:33 AM
To: [email-masked]
Cc: [email-masked]; 'sipping WG'; [email-masked]; [email-masked]
Subject: [Sipping] FW: I-D ACTION:draft-sriram-sipping-poc-lip-01.txt 

-- juha

---

From: Dean Willis <[email-masked]>
Date: Thu, 25 Aug 2005 15:43:44 -0500

> be consumed for these kind of walled garden problems.

Two points in response to the bait:

RFC 2804 says:

    - On the other hand, the IETF believes that mechanisms designed to
      facilitate or enable wiretapping, or methods of using other
      facilities for such purposes, should be openly described, so as to
      ensure the maximum review of the mechanisms and ensure that they
      adhere as closely as possible to their design constraints. The IETF
      believes that the publication of such mechanisms, and the
      publication of known weaknesses in such mechanisms, is a Good
      Thing.

So, publication of this, even if meant for a walled garden, is a Good 
Thing according to 2804. So is publicly pointing out the design 
constraints therein, so feel free to offer technical criticism.

As for "Why PoC" -- Today's mobile phone networks have such 
minimal-bandwidth, high-latency connections that all sorts of tricky 
B2BUA stuff and in-network buffering is needed to get them to support 
most of the more complex scenarios. Hence, a need for a rather 
specialized specification. Trust me, you do NOT want these discussions 
happening at IETF -- it doesn't fit here any more than Vint's work on 
the Interplanetary Internet. Yes, mobile networks are potentially more 
alien than Martians . . .

But of all of the questionable manipulations of IETF protocols going on 
in various non-IETF organizations, this is actually one of the most 
defensible. I tried very hard and couldn't find a "good" way to meet 
the requirements without hacking things up, and failed. So for now I'll 
settle for "least offensive" and "doesn't preclude connecting to more 
normal stuff".

--
Dean (writing from an OMA PoC meeting in Montreal. Bonjour!)