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

From: "Schmidt, Christian" <[email-masked]>
Date: Wed, 24 Aug 2005 11:30:03 +0200

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?

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?

3.2 ACR
- In the first section, you describe ACR, but not the override mechanism. You should add an explanation here.
- 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."
- "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.

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."

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

Regards
Christian Schmidt

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Miguel Garcia
Gesendet: Dienstag, 23. August 2005 11:35
An: [email-masked]
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:[email-masked]
Nokia Research Center      Helsinki, Finland

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 24 Aug 2005 13:01:49 +0300

Hi Christian:

Thansk for reading this document. Inline comments.

> 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.

> 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.

> - 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…

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.

> 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.

> 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