Re: AW: [Sipping-tispan] TISPAN requirements, first requiements

Miguel Garcia <Miguel.An.Garcia@nokia.com> Wed, 24 August 2005 10:04 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7s7D-0001d9-55; Wed, 24 Aug 2005 06:04:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7s7C-0001d4-0A for sipping-tispan@megatron.ietf.org; Wed, 24 Aug 2005 06:04:14 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10838 for <sipping-tispan@ietf.org>; Wed, 24 Aug 2005 06:04:11 -0400 (EDT)
Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7s7S-00029F-VY for sipping-tispan@ietf.org; Wed, 24 Aug 2005 06:04:32 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7OA4Afs014352; Wed, 24 Aug 2005 13:04:10 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Aug 2005 13:04:09 +0300
Received: from [127.0.0.1] ([172.21.36.151]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 24 Aug 2005 13:01:50 +0300
Message-ID: <430C458D.6080908@nokia.com>
Date: Wed, 24 Aug 2005 13:01:49 +0300
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: "Schmidt, Christian" <christian-schmidt@siemens.com>
Subject: Re: AW: [Sipping-tispan] TISPAN requirements, first requiements
References: <72963DDDF17D7949ABD18DC5DA58E7700583E3@MCHP7R5A.ww002.siemens.net>
In-Reply-To: <72963DDDF17D7949ABD18DC5DA58E7700583E3@MCHP7R5A.ww002.siemens.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 24 Aug 2005 10:01:50.0765 (UTC) FILETIME=[D8E735D0:01C5A892]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext02.nokia.com id j7OA4Afs014352
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Content-Transfer-Encoding: quoted-printable
Cc: sipping-tispan@ietf.org, "Alexeitsev, D" <D.Alexeitsev@t-com.net>
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

Hi Christian:

Thansk for reading this document. Inline comments.

Schmidt, Christian wrote:

> Some comments:
> 
> 2. Overview
> "small variations are expected when compared with the equivalent ISTD/PSTN supplementary services"
> Can you provide an example for such a variation?

I'll give you one example that came to my mind. Many of the 
supplementary services in PSTN/ISDN assume that there is only one 
line/terminal per user, so if the user is already busy from that 
terminal/line, he won't be able to take a new call, thus, services such 
as Call Forwarding on Busy will apply.

This is not exactly the same in SIP, where a user can be using several 
terminal simultaneously, and there isn't a concept of a "line" or 
"channel". Therefore, the fact that a user is busy from one terminal 
does not necessarily imply anything with respect his busy condition. 
This is a change with respect the PSTN/ISDN services.

In addition to that, one can expect that the SIP simulation services are 
applicable to any type of communication, not only to "voice calls", 
which is the assumption in the PSTN. So if I apply the Originating 
Identity Restriction service to not present my identity to the called 
part, I will expect that the same service is applicable when I send an 
Instant Message to that party.

> 
> 3.1 General Requirements
> "the user should receive the service without any degradation"
> This seems to be somehow in contradiction with the "variation" passage in the overview section. Or do you mean variation as addon only?

The requirement means that, if one user is in the NGN and the other in 
the PSTN, the NGN user should not receive a degradation with respect the 
NGN simulation service (read the "native network" in the text). 
Similarly, the PSTN user should not receive a degradation with respect 
the PSTN/ISDN supplementary service provided in the PSTN.

I think this isn't in contradiction with the "variation" passage.

> 
> 3.2 ACR
> - In the first section, you describe ACR, but not the override mechanism. You should add an explanation here.

Good point, I will add it.

> - ACR2: the term "allowing the callee to receive" is somehow missleading. According to my understanding, the callee cannot influence the delivery of such calls. Proposal: "allowing anonymous calls to be provided to callees, in spite of an activated ACR service."

Agree, I will reword it.

> - "This is needed...". This is not a requirement, it is an explanation and should be part of the service description at the begin of the section.

Agree also, will move it to the explanation.

> 
> There should also be a general requirement included:
> GEN-3: "SIP UA not providing this simulation service should not be influenced, they are simple not able to provide the related service."

I agree with the idea, but I don't think it is a requirement, but a 
property or expectation of the system. But I can add some clarification 
text indicating that we don't expect SIP UAs that do not implement the 
services to provide the service to the user.

> 
> Security Considerations:
> Idea:
> Threat: Fake override condition
> Method: How to avoid, for example with a short description of the planned authentication and authorization methods.

Well, yes, the security considerations section requires obviously quite 
a lot of work. I can start adding some words about it.

Thanks a lot,

         Miguel
> 
> Regards
> Christian Schmidt
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: sipping-tispan-bounces@ietf.org [mailto:sipping-tispan-bounces@ietf.org] Im Auftrag von Miguel Garcia
> Gesendet: Dienstag, 23. August 2005 11:35
> An: sipping-tispan@ietf.org
> Cc: Alexeitsev, D
> Betreff: [Sipping-tispan] TISPAN requirements, first requiements
> 
> 
> Folks:
> 
> Since we are tasked to re-draft the TISPAN requirements adding as much 
> clarifications as possible, we would like to start checking with you if 
> the requirements related to the Annonymous Communication Rejection (ACR) 
> service is OK and understandable by everyone.
> 
> So please take a look at the first version of the (much incomplete and 
> short) draft in either text or HTML:
> 
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02a.txt
> http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipping-tispan-requirements-02a.html
> 
> The document is fairly short at the moment. Please post your comments here.
> 
> /Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:miguel.an.garcia@openlaboratory.net
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan