RE: [Sipping] draft-watson-sipping-req-history-01

["Dean Willis" <dean.willis@softarmor.com>]

> I'll avoid reacting to the tacky part of this email and go 
> straight to your last comment on the security/privacy 
> mechanisms.  As I mention in the email reponse to Frank's 
> initial posting, we have added quite a bit to the updated -02 
> draft on this topic.  We'd definitely appreciate feedback on 
> whether these requirements address these "really hideous 
> interactions" to which you refer.  Personally, I think these 
> interactions are only slightly more "hideous" than the 
> "normal" security/privacy mechanisms which several other 
> drafts are also needing to address.


Thanks for your restraint, Mary, and for following up with the reference
to the new draft version. I do think we're making progess towards a
reasonable concept of history.

Ok, so I didn't manage to not sound tacky. I'm sorry.

Request-history can be used to replicate the PSTN, and many of us think
this is not a good idea and therefore react with instinctive horror
whenever somebody brings it up. However, the argument has been made (and
it seems plausible) that request-history can be used appropriately to
build new types of services, etc. 

My problem is that I don't know how to steer the discussion of
request-history toward such usages, as the PSTN-replication stuff keeps
popping up like the robot moles in the "whack a mole" game, and if it
doesn't get whacked pretty quickly somebody starts running with it and
the next thing we have is a standardized call model with ITU reference
triggers.

As for the security interactions -- if you don't consider the debate
we've had over the last two years about
privacy/security/confidentiality/identity/caller-ID to be in and of
itself "hideous" (or at least really complicated and painful) then
you're a dramatically more sympathetic and tolerant person than I am.
Clearly, information such as why a request was retargted is as sensitive
and and its protection as complex as is the identity of the party making
a request, and its interworking with PSTN suffers from the same "trusted
net, untrusted client" vs. "untrusted net, trusted client" schism that
affects identity. It's going to be interesting at the least.

--
Dean


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP