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

From: "Jesske, R" <[email-masked]>
Date: Thu, 25 Aug 2005 10:52:09 +0200

Paul,
I hope we do understand in future. Next Try. See below.

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Donnerstag, 25. August 2005 05:31
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]; 
> Alexeitsev, Denis
> Betreff: Re: AW: [Sipping-tispan] TISPAN requirements, first 
> requiements
> 
> 
> 
> 
> Jesske, R wrote:
> > Paul,
> > With regard to this feature it must be based on trust 
> relationship as defined within RFC3325 for the P-Asserted-Identity.
> > So the indication that this is a authorised user is 
> included by a network entity like it is done for the 
> P-Asserted-Identiy.
> > So the network entity knows it via a database that this 
> registered user is a authorised one.
> 
> Either I don't understand you, or you don't understand me.
> 
> RFC3325 is a way for some trusted element of the network that 
> knows the 
> source of the request to assert a trusted identity for the 
> source of the 
> message. It doesn't provide any authorization for anything.
For the Marking of a call with a bypass allowance a network element must include on behalf of the user this element so that a Police-call is really a police call.
I will try it with some flows:

Police
  UA:A        Proxy            ACR          UA:B
   ------------->  ----------->   -----------> 
   F1:INVITE         F2:INVITE     F3:INVITE

F1: INVITE
No indications 
From: Anonymous

F2: INVITE
A indication is added indicating that this communication comes from a official authority (Police)
From: Anonymous
P-Asserted-Identity with privacy Id

F3: INVITE
ACR server forwards the communication due to the  bypass indication
From: Anonymous

PSTN         PSTN/ISDN
  User A         GW           ACR          UA:B
   ------------->  ----------->   -----------> 
   F1:IAM           F2:INVITE     F3:INVITE

F1: IAM:
No Calling Party number is included
Call is marked as restricted by the network

F2: INVITE
A indication is included that points to the fact that the call is Anonymous because of a network restriction
 From: Anonymous
P-Asserted-Identity absent 

F3: INVITE
ACR server forwards the communication due to the  indication that the communication is anonymous because of network restriction
From: Anonymous

Untrusted    my network
 ProxyA       Proxy B            ACR          UA:B
   ------------->  ----------->   
   F1:INVITE         F2:INVITE     

F1: INVITE
No indications 
From: Anonymous
No P-Asserted-Identity

F2: INVITE
No indication will be added because the request comes from an untrusted proxy
From: Anonymous
No Privacy

ACR rejects the communication

> 
> Ultimately, the ACR service must be implemented near and on behalf of 
> the recipient of the message. It isn't until there that it is 
> known that 
> there is any service to authorize. At that point, the P-Asserted-ID 
> header may be present, but that just says who the caller is, not what 
> role the caller is playing. It seems that you want to do role based 
> authorization, where the role is "entitled-to-override-ACR".
> 
> So how is this role determined? Surely the recipient can't 
> have a DB of 
> all values of P-Asserted-ID that are authorized. The 
> alternative seems 
> to be that the source inserts not just a simple P-Asserted-ID with a 
> name, but rather also inserts some kind of role identification.

That could be the way out. That such a indication shall be bind to the P-Asserted identity and is included by the originating network-entity.
Because we bind the ACR service to the P-Asserted-Identity.

We reject the communication if a P-Asserted-Identity is included and the priv value is "Id", "user","header" and /or ""critical" and if the P-Asserted-Identity is absent.

> 
> I'm looking for more indication of what the expectations are in this 
> regard. Is it the expectation that the source will annotate 
> every call 
> with an indication that the caller is permitted to override 
> ACR? 

Yes.

>Or with 
> some other more generic categorization of caller type? 

That could be also a possibility. For solving the police communications but it makes it not easy with the ISDN/PSTN interworking. Because if we have such a caller type (What is also another requirement) than we have to distinguish at the Interworking Unit. Because some caller types can be mapped to the Calling parties category and others must be mapped to the network restriction indication.

>Or what?

> 
> > With regard to the PSTN/ISDN this was solved via a 
> indication that the Calling Party Number is restricted by the 
> network. The network included this indication in three cases:
> > 1. The call was originated within a network that cannot 
> provide a originating number (e.G.) analogue.
> > 2. The call has no originated number due to interworking 
> with international networks
> > 3. The call was send from a authorised user (e.G. police). 
> This indication was then set by the network. This feature is 
> especially used in UK.
> 
> So you are looking for some kind of enhancement to Privacy, that 
> indicates *why* privacy is requested?

>From my point of view YES.

First Idea was to have a privacy value that says "network restricted" (as it is in the PSTN/ISDN) to express that the Id is missing because of some network restrictions (like interworking, Analogue originating or such police calls). Because to add such value to the privacy header would be easy.
But people had the opinion that this has nothing to do with privacy. So we looked fore some other possibility. That is what I have showed you above.

I hope that this was better that we can come together and you understand me.

Roland

> 
> 	Paul
> 
> > So with the requirement proposed by Miguel we hope to find 
> a solution to cover the 3 above mentioned cases.
> > 
> > With regard to trust we want to have such a indication bind 
> to a trust relationship as it is described within RFC3325.
> > So trust for interconnection to an other network is based 
> on bilateral agreement.
> > 
> > 
> > Best Regards
> > 
> > Roland
> > 
> > 
> >>-----Ursprüngliche Nachricht-----
> >>Von: [email-masked] 
> >>[mailto:[email-masked]] Im Auftrag von Paul Kyzivat
> >>Gesendet: Mittwoch, 24. August 2005 05:07
> >>An: Miguel Garcia
> >>Cc: [email-masked]; Alexeitsev, Denis
> >>Betreff: Re: [Sipping-tispan] TISPAN requirements, first requiements
> >>
> >>
> >>
> >>
> >>Miguel Garcia wrote:
> >>
> >>>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-sippin
> > 
> > g-tispan-requirements-02a.txt 
> > 
> >>http://people.nokia.net/~miguel/drafts/pre/draft-jesske-sipp
ing-tispan-requirements-02a.html 
>>
>>
>>The document is fairly short at the moment. Please post your comments here.
> 
> 
> Regarding REQ-ACR-2:
> 
> 
>>   REQ-ACR-2: It must be possible that authorized callers are not
>>              subject to the ACR service, thus, allowing the callee to
>>              receive anonymous requests from authorized callers.  This
>>              effectively requires a mechanism to override the ACR
>>              service depending on the identity and authorization of the
>>              caller.  This is needed, e.g., when a police officer or
>>              any other authority is anonymously calling to a user
>>              having the ACR simulation service activated.
> 
> 
> How is a caller authorized? Is the mechanism for determining and 
> conveying this authorization in scope for this service? There is mention 
> specifically of Police Officers, among others, as being authorized. Are 
> there a list of attributes like that which must be used to characterize 
> a caller and that are used to determine the authorization?
> 
> How is this affected by peering and PSTN interconnect? Is an 
> authorization on one side to be conveyed to the other side and then 
> trusted their?
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> 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: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 25 Aug 2005 08:47:14 -0400

Let's just summarize the requirement.  You've tied it to other mechanism 
below.  I think it will be less confusing to abstract out the actual 
information that is needed.

So: the requirement is that it be possible to include in SIP signalling 
an indicator that network-provided Anonymous Call Rejection should be 
overridden.  This is needed in two circumstances: when the caller 
identity is unavailable in the first place, and when Privacy is invoked. 
  There is an obvious ancillary requirement that this indicator be acted 
on only if it comes from a trusted source.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 25 Aug 2005 16:01:58 +0300

Tom:

I agree with you in the essence, but you are referring to a solution, 
not to a requirement. Essentially, whenever you need to speak about an 
"indicator", it raises an alarm in my head that you are speaking about a 
possible solution rather than a requirement.

So the requirement is tha there are certain anonymous users that are not 
subject to be filtered by ACR. Then we can further discuss the solution, 
which is probably going in the direction you suggest.

/Miguel

Tom-PT Taylor wrote:

>>> Von: Paul Kyzivat [mailto:[email-masked]] Gesendet: Donnerstag, 
>>> 25. August 2005 05:31
>>> An: Jesske, Roland
>>> Cc: [email-masked]; [email-masked]; Alexeitsev, 
>>> Denis
>>> Betreff: Re: AW: [Sipping-tispan] TISPAN requirements, first requiements
>>>
>>>
>>>
>>>
>>> Jesske, R wrote:
>>>
>>>> Paul,
>>> included by a network entity like it is done for the P-Asserted-Identiy.
>>>
>>> RFC3325 is a way for some trusted element of the network that knows 
>>> the source of the request to assert a trusted identity for the source 
>>> of the message. It doesn't provide any authorization for anything.
>>
>>
>> For the Marking of a call with a bypass allowance a network element 
>> must include on behalf of the user this element so that a Police-call 
>> is really a police call.
>>    ------------->  ----------->   ----------->    F1:INVITE         
>> F2:INVITE     F3:INVITE
>>
>>
>> F1: INVITE
>> No indications From: Anonymous
>>
>> F2: INVITE
>>    ------------->  ----------->   ----------->    F1:IAM           
>> F2:INVITE     F3:INVITE
>>
>> F1: IAM:
>> A indication is included that points to the fact that the call is 
>> Anonymous because of a network restriction
>>  From: Anonymous
>> ACR server forwards the communication due to the  indication that the 
>> communication is anonymous because of network restriction
>> From: Anonymous
>>
>> Untrusted    my network
>>  ProxyA       Proxy B            ACR          UA:B
>>    ------------->  ----------->      F1:INVITE         F2:INVITE    
>>
>> F1: INVITE
>> No indications From: Anonymous
>> No P-Asserted-Identity
>>
>> F2: INVITE
>>> the recipient of the message. It isn't until there that it is known 
>>> that there is any service to authorize. At that point, the 
>>> P-Asserted-ID header may be present, but that just says who the 
>>> caller is, not what role the caller is playing. It seems that you 
>>> want to do role based authorization, where the role is 
>>> "entitled-to-override-ACR".
>>>
>>> So how is this role determined? Surely the recipient can't have a DB 
>>> of all values of P-Asserted-ID that are authorized. The alternative 
>>> seems to be that the source inserts not just a simple P-Asserted-ID 
>>> with a name, but rather also inserts some kind of role identification.
>>
>>
>>
>> That could be the way out. That such a indication shall be bind to the 
>> P-Asserted identity and is included by the originating network-entity.
>> We reject the communication if a P-Asserted-Identity is included and 
>> the priv value is "Id", "user","header" and /or ""critical" and if the 
>> P-Asserted-Identity is absent.
>>
>>
>>> regard. Is it the expectation that the source will annotate every 
>>> call with an indication that the caller is permitted to override ACR? 
>>
>>
>>
>> Yes.
>>
>>
>>> Or with some other more generic categorization of caller type? 
>>
>>
>>
>> That could be also a possibility. For solving the police 
>> communications but it makes it not easy with the ISDN/PSTN 
>> interworking. Because if we have such a caller type (What is also 
>> another requirement) than we have to distinguish at the Interworking 
>> Unit. Because some caller types can be mapped to the Calling parties 
>> category and others must be mapped to the network restriction indication.
>>
>>
>>> Or what?
>>
>>
>>
>>
>> First Idea was to have a privacy value that says "network restricted" 
>> (as it is in the PSTN/ISDN) to express that the Id is missing because 
>> of some network restrictions (like interworking, Analogue originating 
>> or such police calls). Because to add such value to the privacy header 
>> would be easy.
>> But people had the opinion that this has nothing to do with privacy. 
>> So we looked fore some other possibility. That is what I have showed 
>> you above.
>>
>>> conveying this authorization in scope for this service? There is 
>>> mention specifically of Police Officers, among others, as being 
>>> authorized. Are there a list of attributes like that which must be 
>>> used to characterize a caller and that are used to determine the 
>>> authorization?
>>>

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 25 Aug 2005 09:19:50 -0400

Perhaps I should have used the phrase "SIP signalling must include the 
information that ...".  Your phrasing itself puts the focus on the 
anonymous users.  This is relevant to the actions at the point where my 
piece of information is inserted, but not to anything downstream of 
that.  I believe the downstream aspects are what matter in our current 
discussion, because these are where new mechanisms, if any, may be 
required.

Miguel Garcia wrote:
>> Let's just summarize the requirement.  You've tied it to other 
>> mechanism below.  I think it will be less confusing to abstract out 
>> the actual information that is needed.
>>
>> So: the requirement is that it be possible to include in SIP 
>> signalling an indicator that network-provided Anonymous Call Rejection 
>> should be overridden.  This is needed in two circumstances: when the 
>> caller identity is unavailable in the first place, and when Privacy is 
>> invoked.  There is an obvious ancillary requirement that this 
>> indicator be acted on only if it comes from a trusted source.
>>
>> Jesske, R wrote:
>>
>>> Paul,
>>>> the source of the request to assert a trusted identity for the 
>>>> source of the message. It doesn't provide any authorization for 
>>>> anything.
>>>
>>>
>>>
>>>> Ultimately, the ACR service must be implemented near and on behalf 
>>>> of the recipient of the message. It isn't until there that it is 
>>>> known that there is any service to authorize. At that point, the 
>>> That could be the way out. That such a indication shall be bind to 
>>> the P-Asserted identity and is included by the originating 
>>> network-entity.
>>> the priv value is "Id", "user","header" and /or ""critical" and if 
>>> the P-Asserted-Identity is absent.
>>>
>>>
>>> or such police calls). Because to add such value to the privacy 
>>> header would be easy.

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 25 Aug 2005 16:24:23 +0300

It does not change anything, you are assuming a solution: "the 
signalling carries some information that... "

/Miguel

Tom-PT Taylor wrote:

>> "indicator", it raises an alarm in my head that you are speaking about 
>> a possible solution rather than a requirement.
>>
>> So the requirement is tha there are certain anonymous users that are 
>> not subject to be filtered by ACR. Then we can further discuss the 
>> solution, which is probably going in the direction you suggest.
>>
>> /Miguel
>>
>> Tom-PT Taylor wrote:
>>
>>> signalling an indicator that network-provided Anonymous Call 
>>> Rejection should be overridden.  This is needed in two circumstances: 
>>> when the caller identity is unavailable in the first place, and when 
>>> Privacy is invoked.  There is an obvious ancillary requirement that 
>>> this indicator be acted on only if it comes from a trusted source.
>>>
>>> Jesske, R wrote:
>>>
>>>> Paul,
>>>> must include on behalf of the user this element so that a 
>>>> Police-call is really a police call.
>>>> ACR server forwards the communication due to the  indication that 
>>>> the communication is anonymous because of network restriction
>>>> From: Anonymous
>>>>
>>>> Untrusted    my network
>>>>  ProxyA       Proxy B            ACR          UA:B
>>>>> So how is this role determined? Surely the recipient can't have a 
>>>>> DB of all values of P-Asserted-ID that are authorized. The 
>>>>> alternative seems to be that the source inserts not just a simple 
>>>>> P-Asserted-ID with a name, but rather also inserts some kind of 
>>>>> role identification.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> I'm looking for more indication of what the expectations are in 
>>>>> this regard. Is it the expectation that the source will annotate 
>>>>> every call with an indication that the caller is permitted to 
>>>>> override ACR? 
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Yes.
>>>>
>>>>
>>>> First Idea was to have a privacy value that says "network 
>>>> restricted" (as it is in the PSTN/ISDN) to express that the Id is 
>>>> missing because of some network restrictions (like interworking, 
>>>> Analogue originating or such police calls). Because to add such 
>>>> value to the privacy header would be easy.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 25 Aug 2005 09:36:09 -0400

I think your requirement is not quite accurate even at this level of 
abstraction.  Roland has identified two different cases.  One is your 
"certain anonymous users", but the other is the case where the user 
identity is unable due to the network's inability to provide it.

I guess I can see your point about pushing too hastily to mechanism. 
Roland actually identified the information that might be used to resolve 
the issue at the rejection point: on the one hand, the identity of the 
caller if present in a P-A-Id, and on the other hand, the absence of a 
P-A-Id.  It may be that this is all that is needed, and no further 
discussion is required in SIPPING.  (Of course, that's assuming that the 
number of authorized caller identities any one rejection point has to 
keep track of is limited and provisionable.)

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 25 Aug 2005 16:41:02 +0300

So what is an anonymous user? An anonymous user is one for which his 
identity is not determined. The reason why a user is anonymous is 
another story (the user want, or the network can't provide an identity), 
but they are anonymous in both cases.

/Miguel

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 25 Aug 2005 09:59:23 -0400

You are missing a case.  The distinction is whether the caller is 
anonymous to the network as well as to the called party.  So one of the 
ACR cases is when the network has the identity of the caller but will 
not disclose it due to operation of the Privacy service.

Miguel Garcia wrote:
>> Roland actually identified the information that might be used to 
>> resolve the issue at the rejection point: on the one hand, the 
>> identity of the caller if present in a P-A-Id, and on the other hand, 
>> the absence of a P-A-Id.  It may be that this is all that is needed, 
>> and no further discussion is required in SIPPING.  (Of course, that's 
>> assuming that the number of authorized caller identities any one 
>> rejection point has to keep track of is limited and provisionable.)
>>
>> Miguel Garcia wrote:
>>
>>> Tom:
>>>
>>> not to a requirement. Essentially, whenever you need to speak about 
>>> an "indicator", it raises an alarm in my head that you are speaking 
>>> about a possible solution rather than a requirement.
>>>
...

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2005 00:36:16 -0400

I've tried to trim out what is no longer relevant. Further comments inline.

	Paul

> I will try it with some flows:

I'm still having trouble deciding who is responsible for what.
I presume Proxy is acting on behalf of the call initiator, and makes the 
authentication decisions that this is from the police.

I presume that ACR is acting on behalf of the recipient B. It is 
presented with the request asserting that the call is from the Police, 
and must make the authorization decision that ACR should be bypassed. 
Presumably it must know that Police get this right, as perhaps do Fire, 
Operator, and maybe some others.

If so, can one ACR implentation allow both Police and Fire, while 
another allows only Police?

This seems to require a taxonomy of types of callers as well as a 
specification of which of those types are to be entitled to bypass ACR.

This certainly does seem to be an instance of role based authentication 
and authorization. I think it ought to be discussed as such.

>   User A         GW           ACR          UA:B

This case is a little different. While I can accept "police", "fire", 
"operator", etc. as roles, I find it pretty difficult to accept "no 
identity available" as a role.

I think it would be better to not treat such calls as anonymous at all. 
Instead, I think some P-Asserted-ID value should be assigned to this 
call. It can be something generic, but will still be an ID.

>  ProxyA       Proxy B            ACR          UA:B

I think it might be worth considering adding role parameters to 
P-Asserted-ID.

But it still remains to at least enumerate the roles that are entitled 
to bypass ACR.

> That could be also a possibility. For solving the police communications but it makes it not easy with the ISDN/PSTN interworking. Because if we have such a caller type (What is also another require…

It sounds like there are further requirements - to represent certain 
"network restriction indications".

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2005 00:51:23 -0400

> identity is unable due to the network's inability to provide it.

I agree with Tom on that. But in addition I think there is another 
requirement lurking there: *somebody* has to decide *who* the "certain 
anonyous users" are who qualify. I can't yet tell whether this decision 
is made entirely at the originating end, or partly at the terminating 
end. For instance, as I mentioned in another message, it could be that 
the originating end determines that the caller has the role "police" 
while it is the terminating end that determines that the role "police" 
is entitled to bypass ACR. Or, it could be that the originating end 
explicitly determines that the caller, for whatever reason, is entitled 
to bypass ACR if need be. Or it could be that the terminating end has to 
make the entire decision about whether this caller is entitled to bypass 
  ACR.

So I think something about who is expected to make what part of the 
decision needs to be a requirement.

> keep track of is limited and provisionable.)

I don't think it is very plausible that the receiving end would have 
access to a list of all the police officers (anywhere in world?) that 
are entitled to this treatment.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 26 Aug 2005 10:23:05 +0300

So Paul seems to be suggesting to add a requirement indicating that 
someone has to authorize the identities, (perhaps based in roles, 
perhaps in URIs) who can bypass ACR. I think this is a role ACR service 
provider. So what about if we add one more requirement along these lines:

"It must be possible for the the ACR service provider to determine the 
callers who can bypass the ACR service of the callee."

On the solution space, I think we are heading to adding something like a 
  role parameter to the P-Asserted-Identity. Using the trust required by 
P-Asserted-Identity, it is possiblet that the ACR service provider if it 
trusts a P-Asserted-Identity it will also trust the role parameter, than 
can take the format of "police", "fire", or whatever is needed.

Comments?

/Miguel

Paul Kyzivat wrote:

>>>> Rejection should be overridden.  This is needed in two 
>>>> circumstances: when the caller identity is unavailable in the first 
>>>> place, and when Privacy is invoked.  There is an obvious ancillary 
>>>> requirement that this indicator be acted on only if it comes from a 
>>>> trusted source.
>>>>
>>>> Jesske, R wrote:
>>>>
>>>>> Paul,
>>>>>> Von: Paul Kyzivat [mailto:[email-masked]] Gesendet: 
>>>>>> Donnerstag, 25. August 2005 05:31
>>>>>> An: Jesske, Roland
>>>>>> knows the source of the request to assert a trusted identity for 
>>>>>> the source of the message. It doesn't provide any authorization 
>>>>>> for anything.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> We reject the communication if a P-Asserted-Identity is included 
>>>>> and the priv value is "Id", "user","header" and /or ""critical" and 
>>>>> if the P-Asserted-Identity is absent.
>>>>>
>>>>>
>>>>> another requirement) than we have to distinguish at the 
>>>>> Interworking Unit. Because some caller types can be mapped to the 
>>>>> Calling parties category and others must be mapped to the network 
>>>>> restriction indication.
>>>>>
>>>>>
>>>>>> Or what?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> But people had the opinion that this has nothing to do with 
>>>>> privacy. So we looked fore some other possibility. That is what I 
>>>>> have showed you above.
>>>>>
>>>>>> authorization on one side to be conveyed to the other side and 
>>>>>> then trusted their?
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Aug 2005 17:35:55 -0400

> callers who can bypass the ACR service of the callee."

I see you have added this to the new draft, and I think it is a step in 
the right direction. But I am not sure it is yet quite right.

The problem I am having is that this is framed as if there is only one 
decision making element. I think there are at least two, and this is not 
made clear. Specifically, I think there is an originating network and a 
terminating network. They may, but need not, be the same network. In 
particular, one may be the PSTN, and the other may be a "tispan" sip 
network. That is one form of peering, and there may be other forms of 
peering as well, that would also give rise to different originating and 
terminating networks.

In the case where the originating and terminating networks are 
different, there is some division of responsibility between the two 
regarding how the ACR service (part of the terminating network) 
determines which callers can bypass the ACR service.

I'm still not sure what that division of responsibility is, but I 
suspect there is a requirement for it to be a particular way, which 
needs to be specified. I can think of at least a couple of different 
divisions:

1) the originating network makes the determination about which calls
    are to bypass ACR if it is present, and delivers the decision
    to the terminating network in some way. The terminating network
    (the ACR function) simply acts on this determination
    unconditionally.

2) the originating network categorizes each call, using categories
    known to both the originating and terminating network. The
    terminating network (the ACR function) determines which calls
    are to bypass ACR, using the categorization and/or some other
    way at its discretion.

There may indeed be legal implications to this, especially in the case 
of calls that cross juristictional boundaries.  So I think it is 
important to nail down what the requires are.

I am starting to get the impression that the answer is (1), but I am far 
from certain about that.

	Paul

>> anonyous users" are who qualify. I can't yet tell whether this 
>> decision is made entirely at the originating end, or partly at the 
>> terminating end. For instance, as I mentioned in another message, it 
>> could be that the originating end determines that the caller has the 
>> role "police" while it is the terminating end that determines that the 
>> role "police" is entitled to bypass ACR. Or, it could be that the 
>> originating end explicitly determines that the caller, for whatever 
>> reason, is entitled to bypass ACR if need be. Or it could be that the 
>> terminating end has to make the entire decision about whether this 
>> caller is entitled to bypass  ACR.
>>
>>>> I agree with you in the essence, but you are referring to a 
>>>> solution, not to a requirement. Essentially, whenever you need to 
>>>> speak about an "indicator", it raises an alarm in my head that you 
>>>> are speaking about a possible solution rather than a requirement.
>>>>
>>>>>> For the Marking of a call with a bypass allowance a network 
>>>>>> element must include on behalf of the user this element so that a 
>>>>>>> Ultimately, the ACR service must be implemented near and on 
>>>>>>> behalf of the recipient of the message. It isn't until there that 
>>>>>>> it is known that there is any service to authorize. At that 
>>>>>>> point, the P-Asserted-ID header may be present, but that just 
>>>>>>> says who the caller is, not what role the caller is playing. It 
>>>>>>> seems that you want to do role based authorization, where the 
>>>>>>> role is "entitled-to-override-ACR".
>>>>>>>
>>>>>> and the priv value is "Id", "user","header" and /or ""critical" 
>>>>>> and if the P-Asserted-Identity is absent.
>>>>>>
>>>>>>
>>>>>>> authorized. Are there a list of attributes like that which must 
>>>>>>> be used to characterize a caller and that are used to determine 
>>>>>>> the authorization?
>>>>>>>