Subject: Re: [cuss] Use Cases for REQ-9

From: Alan Johnston <[email-masked]>
Date: Wed, 3 Nov 2010 09:34:15 -0500

Keith,

I think you are correct that the major use will be removal of UUI
information from a request by border elements.  I can't think of any use
cases for blocking.

I am OK with your proposed wording.

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

Unless others can propose use cases for the blocking (i.e. rejection) or a
request due to the presence of UUI, then I will make this change to the
requirements document.

- Alan -

On Fri, Oct 1, 2010 at 3:43 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> 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.
> >
> > On the call, there was a request for use cases to go with
> > this mechanism.
> >
> > - Alan -
> > _______________________________________________
> > cuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cuss
> >