 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
At 08:49 PM 7/19/2008, Richard Barnes wrote:
James,Not proposing that there's some sort of "gauntlet" that SIP/PIDF extensions need to run. Just that we need to acknowledge the possibility of incremental privacy risks that they might introduce and consider how those risks should be mitigated.
This seems to me to be something your ID can talk about, as long as it's a look at the new information in the extension to SIP/Presence. But where do we record this"look" as being 'ok' or 'not ok' with the privacy concerns to Geopriv? I'm concerned about the formality of this, yet sympathetic to where I think you're going.
All this is really saying is that using SIP presence doesn't give you a free pass for security and privacy considerations. (SECDIR wouldn't let you have that pass anyway.)
yeah but... I'm wondering if SECDIR will have the awareness that a particular new feature/function breaks Geopriv privacy concerns - especially if a particular extension has nothing originally to do with location...
I agree in concept that there shouldn't be any free pass - but how do you propose monitoring occur that has a chance of success?
--Richard James M. Polk wrote:At 04:11 PM 7/17/2008, Richard Barnes wrote:I think where Hannes was going is that this document does make a meaningful change to the SIP presence system. It does so by including a new type of information, which could introduce different privacy risks.ok, so let me get this straight - and this goes directly to the firm comment you made on the WiMAX call Monday -- you claimed then that every single change in PIDF forces PIDF-LO to go back through the gauntlet of re-qualifying SIP as a "Using Protocol". Are you serious? Where's the requirement for the snapshot of PIDF information that marks the point in time that Presence achieved this status (as a "Using Protocol"), with the understanding that for EVERY single extension to Presence from that moment forward it rescinds that status until some magical requalification takes place (from a new snapshot of Presence)? You're proposing that any extension to PIDF, regardless of what SIP or SIPPING or SIMPLE does int he future - MUST require a new re-qualification of SIP to carry this PIDF as a message body.This extension is analogous to the transition between PIDF and PIDF-LO: You're still just putting a PIDF in SUB/NOT. There are two separate RFCs to deal with that extension (3693/3694). So even though you're just adding something to a PIDF (or PIDF-LO), there might still be cause for some security and privacy discussions.How many others on this list agree with this undertaking?I think we're making this out to be a bigger deal than it really is. I think the "sniff test" should be all that's required, with things that smell odd getting a more thorough look at.James--Richard James M. Polk wrote:At 02:03 PM 7/17/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:Hannes PS: You write "poses zero new security or privacy concerns relative to Conveyance." Let me give you something to think about: When you change one protocol name against another one then do you think that the fundamental privacy & security aspects are suddenly different?"one protocol against another" huh? Conveyance already has PIDF-LO within SIP SUBSCRIBE and NOTIFY.There is nothing new in either of these IDs relative putting a PIDF-LO in SUBSCRIBE or NOTIFY.What do you see that's fundamentally different? _______________________________________________ Geopriv mailing list Geopriv at ietf.org https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________ Geopriv mailing list Geopriv at ietf.org https://www.ietf.org/mailman/listinfo/geopriv