Re: [Sipping-tispan] ACR Requirements

[Paul Kyzivat <[e-mail]>]

Jesske, R wrote:
> Dear all,
> After several discussions I had the last days regarding the ACR 
> requirements I would like to propose the following:
> 
> 1. To define a requirement that marks a communication where the ID is 
> network restricted. The rest with regard to ACR is the definition how 
> the service will use such a network restricted information.
> 
> E.G
> [ACR-2] To avoid that the ACR rejects communications that have no 
> originating Identity due to the fact that this was restricted by the 
> network and not by a privacy service initiated or initiated on behalf by 
> the originator of the communication a indication is needed to mark that 
> communication as a network restricted communication.

I think I understand what you mean. But I am a little troubled by the 
term "restricted" for this. I suppose it is enshrined by prior use, but 
it seems to convey the wrong implications to me. It implies that the may 
still be known to the network, but withheld at the whim of the network 
rather than at the whim of the user, and that somehow that is ok.

It would be more comforting to me if you were to use the term "unknown" 
rather than "restricted".

> 2. To delete the by-pass requirement for authorities.
> 
> Due to the bypass of ACR several issues were discussed. Fact is it is 
> not clear if this is required by regulation or not.

That would certainly simplify things.

> It was mentioned 
> that a originating identification is needed. Due to the fact that there 
> is an other requirement ([REQ-CAT-1] For service applicability to 
> special groups and interoperability with the PSTN/ISDN an indication of 
> the originating party category is needed. This is needed due to the fact 
> that some services apply a special behaviour to special user groups 
> (e.g., like Pay-Phones). And [REQ-CAT-2] The originating party category 
> referred to in REQ-CAT-1 must be inserted by a trusted entity. )

At least this would move some of the discussion to another topic, though 
it probably won't make it go away.

> it is 
> proposed to use this functionality then if a bypass is needed. This 
> requirement is independent from the ACR bypass, because a originating 
> user indication (Calling Party's Category) is needed anyway.

But this would then become just another requirement imposed on ACR would 
it not? Using REQ-CAT-1 and REQ-CAT-2 will perhaps factor out the 
determination of category, but the bypass of ACR based on category 
remains. In fact it then becomes an issue to specify exactly which of 
the categories are eligible to bypass ACR. (police:yes, fire:maybe, 
pay-phone:no, prison:certainly.) That decision could be defined for each 
service, or it could be a user option. (But somehow I doubt tispan would 
let this be a user option.)

	Paul

> I hope we can go such a way and solve  the network restricted problem.
> 
> Best Regards
> 
> Roland
> 
> 
> 
> Deutsche Telekom AG
> T-Com Zentrale
> Roland Jesske, TE332-2
> Section TE33; Signalling, Gateways and Switching Systems
> Am Kavalleriesand 3, 64295 Darmstadt, Germany
> Phone:  [phone]
> Fax:      [phone]
> email:  _____ [e-mail]_
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Sipping-tispan mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sipping-tispan

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