Subject: [cuss] Use Cases for REQ-9

From: Alan Johnston <[email-masked]>
Date: Fri, 01 Oct 2010 12:59:34 -0500

REQ-9 is the ability of intermediary devices to block requests
containing UUI or delete UUI from requests.

On the call, there was a request for use cases to go with this mechanism.

- Alan -

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 1 Oct 2010 22:43:53 +0200

The actual requirement is:

   REQ-9: The mechanism will allow proxies to remove a particular type
   of UUI information from a request or response, or to block requests
   based on the presence of a particular type of UUI.

      This is a common security function provided by border elements to
      header fields such as Alert-Info or Call-Info UR

The actual discussion on the call was not the existence or not of the overall requirement, but the extension to particular types of UUI, "a particular type of UUI information from a request or response, or to block requests based on the presence of a particular type of UUI".

As far as the ISDN is concerned there are use cases for blocking UUI, i.e. absence of subscription to the service, support in the sending network but not in the recipient network, and so on. But this relates to the UUI extension as a whole, and does not block on specific usages as for example determined by the protocol discriminator. 

I also believe that as we have so far said we are supporting a preferred service, rather than a required service, in the ISDN, presumably we do not need to block the entire INVITE based on the presence of the UUI, merely remove the UUI.

I guess one could cobble together a use case where some network operator only wants a particular UUI protocol used within their own entities, and therefore some sort of trust domain exists for this application where it is only passed on if the next entity can be trusted to remove it. But I believe such a usage goes against the semantics of UUI, which should be that it is data that the sender only includes if it is prepared for any recipient of the call (even after forwarding) to receive that data. (Indeed maybe here is the basis for another requirement.)

Now obviously there are going to be SBCs out there that offer the flexibility to do all these things, but I don't think we need to suggest functionality to them that is not useful. Moreover, I don't want to be constrained to have to make the service work in the presence of all these additional possibilities. Let us stick to the ones I know we need, which is just straighforward permission to remove.

My revised wording of REQ-9 would therefore be.

   REQ-9: The mechanism will allow proxies to remove UUI information from a request or response.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alan Johnston
> Sent: Friday, October 01, 2010 7:00 PM
> To: [email-masked]
> Subject: [cuss] Use Cases for REQ-9
> 
> REQ-9 is the ability of intermediary devices to block 
> requests containing UUI or delete UUI from requests.
> 
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Oct 2010 23:25:16 +0200

Hi,

Only remove, or also modify and/or add UUI information?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of DRAGE, Keith (Keith) [[email-masked]]
Sent: Friday, October 01, 2010 11:43 PM
To: Alan Johnston; [email-masked]
Subject: Re: [cuss] Use Cases for REQ-9

regards

Keith

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 2 Oct 2010 00:21:37 +0200

For this requirement I would say "remove".

UUI is not SIP data. You need the application that generated it to modify. Likewise you also need an application to create.

These will not exist at a SIP proxy, which by definition is a SIP entity. If you want some other entity to do it, I think you need a new requirement, and you also need to think about the related use cases as well.

Keith 

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: Friday, October 01, 2010 10:25 PM
> To: DRAGE, Keith (Keith); Alan Johnston; [email-masked]
> Subject: RE: [cuss] Use Cases for REQ-9
> 
> Hi,
> 
> From: [email-masked] [[email-masked]] On Behalf 
> Of DRAGE, Keith (Keith) [[email-masked]]
> The actual discussion on the call was not the existence or 
> not of the overall requirement, but the extension to 
> particular types of UUI, "a particular type of UUI 
> information from a request or response, or to block requests 
> based on the presence of a particular type of UUI".
> 
> As far as the ISDN is concerned there are use cases for 
> blocking UUI, i.e. absence of subscription to the service, 
> support in the sending network but not in the recipient 
> network, and so on. But this relates to the UUI extension as 
> a whole, and does not block on specific usages as for example 
> determined by the protocol discriminator.
> 
> I also believe that as we have so far said we are supporting 
> a preferred service, rather than a required service, in the 
> ISDN, presumably we do not need to block the entire INVITE 
> based on the presence of the UUI, merely remove the UUI.
> 
> I guess one could cobble together a use case where some 
> network operator only wants a particular UUI protocol used 
> within their own entities, and therefore some sort of trust 
> domain exists for this application where it is only passed on 
> if the next entity can be trusted to remove it. But I believe 
> such a usage goes against the semantics of UUI, which should 
> be that it is data that the sender only includes if it is 
> prepared for any recipient of the call (even after 
> forwarding) to receive that data. (Indeed maybe here is the 
> basis for another requirement.)
> 
> Now obviously there are going to be SBCs out there that offer 
> the flexibility to do all these things, but I don't think we 
> need to suggest functionality to them that is not useful. 
> Moreover, I don't want to be constrained to have to make the 
> service work in the presence of all these additional 
> possibilities. Let us stick to the ones I know we need, which 
> is just straighforward permission to remove.
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Alan Johnston

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 2 Oct 2010 10:15:07 +0200

Hi,

>UUI is not SIP data. You need the application that generated it to modify. Likewise you also need an >application to create.
>
>These will not exist at a SIP proxy, which by definition is a SIP entity. If you want some other entity to do it, I >think you need a new requirement, and you also need to think about the related use cases as well.

I guess such "application" would be hosted by an B2BUA, which of course would be allowed to add information (since it by definition acts as a UA).

So, as far as proxies are concerned, I guess you are right that "remove" is enough.

Regards,

Christer