Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

From: "Mark Watson"<[email-masked]>
Date: Mon, 15 Apr 2002 19:45:49 +0100

Three problems:
1) In practice you might expect the 'policy' to be more flexible than just
'everything anonymous' (e.g. internal calls non-anonymous, external calls
anonymous), although the blanket anonymity would be the most that Service
Providers could be required to provide. Anyway, we do not want the only
solution to this requirement to be to configure the UA as always anonymous.
 
The users wish is that they be identified if possible. The 'policy' solution
means that the only way of finding out if a particular call must be
anonymous is to try and see, and then retry if it fails.
 
2) Even with a well-crafted UA, why is the _user_ expected to re-configure
their client because of the _subscriber's_ wishes. And when the policy
changes, how will we indicate to all the users that they should now
re-configure their clients again ?
 
I hope all the Service Providers wanting to launch SIP services have got
their list of client requirements worked out. If your subscriber asks for
this anonymity service they will not be impressed if they have to
upgrade/re-configure all their clients. If you didn't inform them in advance
that the clients needed these capabilities, then they could refuse to
upgrade and still demand the anonymity service.
 
3) What about a user who has asked their home proxy to forward calls, and
who wishes to remain anonymous - is the inclusion of this persons identity
in the To field just a policy violation ? How many UAs have an option to set
the To field blank ? This would be more of a 'call rejection' service than a
'call forwarding' service. I think that if in trying to get a Data Protected
version of a service, the user finds that they can't have the service at
all, they would be entitled to be a bit miffed.
 
...Mark

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: 15 April 2002 19:23
To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis;
[email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

OK, in that case I would expect the subscriber profile to have an optional
entry indicating that only anonymous calls were allowed. If some user (the
subscriber or otherwise) then tries to make a non-anonymous call, it gets
rejected.
 
It also makes sense that a well crafted UA that supported anonymous calling
would have an option to always be anonymous, to avoid the usual cycle of try
non-anonymous, fail, then try again with anonymous.
 
I don't see why this is any different than any other rejection due to a
policy violation.

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, April 15, 2002 12:32 PM
To: 'Ben Campbell'; Chiou, Mark; Dean Willis; [email-masked]; [email-masked]
Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

Ben,
 
The user and the subscriber are not the same.
 
See
http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04720.html
<http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04720.html>
for an explanation from earlier today.
 
...Mark

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 15 Apr 2002 14:08:03 -0500

Message
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Mark
Watson
  Sent: Monday, April 15, 2002 1:46 PM
  To: 'Ben Campbell'; Chiou, Mark; Dean Willis; [email-masked];
[email-masked]
  Subject: RE: Summary of RE: [Sip] Comment, SIP Privacy draft

  Three problems:

  Certainly not. I only meant this for the situation where the subscriber
has asserted that all calls from his account are to be anonymous, and an
individual user of that account might not know about that policy choice.

  The users wish is that they be identified if possible. The 'policy'
solution means that the only way of finding out if a particular call must be
anonymous is to try and see, and then retry if it fails.

  Which then allows the user to decide whether or not to continue according
to policy, or just not make the call. Otherwise, the network seems to be in
the business of deciding that the user really does not mind if the call is
anonymous. That seems fairly benign in this particular case, but not
generically (what if the policy was _no_ anonymous calls.)

  They don't have to. Doing so just cuts down on the
reject-due-to-policy-violation-oops-retry cycles. Now, I assume the user
must have some relationship with the subscriber (else how does he have
credentials), and the subscriber _could_ just tell the user. Not everything
has to be automatic.

  Well, once the idea of an anonymity service is fully formed (presumably
what we are doing here) it makes sense that it is a feature that a client
can support or not support. (Maybe even a supported or requires tag?) Then
it is reasonable for a service provider to say you can make anonymous calls
if your client supports anonymity. If a subscriber has a policy of _only_
anonymous calls, and a user has a client that cannot make anonymous calls,
then he is SOL.  I don't see why this is any different than any _other_
situation where an optional client feature might be required by SP or
subscriber policy. Again, the alternative is a presumption on the networks
part that it knows what the user _really_ means to do better than the user
does. Such an presumption on policy violations scares me in the generic
sense.

  ...Mark
    -----Original Message-----
    From: Ben Campbell [mailto:[email-masked]]
    Sent: 15 April 2002 19:23
    To: Watson, Mark [MDN05:EP10:EXCH]; Chiou, Mark; Dean Willis;

    OK, in that case I would expect the subscriber profile to have an
optional entry indicating that only anonymous calls were allowed. If some
user (the subscriber or otherwise) then tries to make a non-anonymous call,
it gets rejected.

    It also makes sense that a well crafted UA that supported anonymous
calling would have an option to always be anonymous, to avoid the usual
cycle of try non-anonymous, fail, then try again with anonymous.

      -----Original Message-----
      From: Mark Watson [mailto:[email-masked]]
      Sent: Monday, April 15, 2002 12:32 PM
      To: 'Ben Campbell'; Chiou, Mark; Dean Willis; [email-masked];
[email-masked]

      Ben,

      See

      ...Mark