Re: [Geopriv] retransmission-allowed is harmful

["Hannes Tschofenig" <[e-mail]>]

Two points: 

A) I guess nobody really thought sufficiently deep enough about conveying
the policies in the style of http://www.ietf.org/rfc/rfc4745.txt /
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-20.txt
together with location information. I suspect that folks say it more as a
vehicle for access control and hence it wouldn't travel around. 

B) In a location URI there is no policy that travels with it (as it is
currently defined). One could, of course, define a URI in the style of
http://tools.ietf.org/html/rfc4467 and attach meta data. We discussed this
several times already but, as far as I remember, never made a decision. It
wouldn't really change anything with the location URI concept as such but
the entity that looks at it would have a clue what the URI actually is. This
would then go into the
http://tools.ietf.org/id/draft-winterbottom-geopriv-held-context-03.txt
document. 

Ciao
Hannes


>I also had other thoughts overnight.  Retransmission-allowed 
>(or something to that effect) is actually helpful on location 
>URIs.  I've made the point previously, but for what it's worth:
>
>Any indication would need to appear in the conveyance protocol 
>associated with the location URI.  A default of "no" needs to 
>be assumed.  A value of "yes" indicates that the rule maker is 
>confident that the LS serving the location URI is able to 
>effectively enforce rules.  Without such an indication, "no" 
>is the only permissible interpretation an LR can make.
>
>Ta,
>Martin
>
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]]
>> Sent: Thursday, 12 March 2009 6:10 PM
>> To: Thomson, Martin; 'GEOPRIV'
>> Subject: RE: [Geopriv] retransmission-allowed is harmful
>> 
>> In previous discussions I mentioned that the basic privacy fields do 
>> not provide enough semantic, see for example 
>> http://www.ietf.org/mail-archive/web/geopriv/current/msg06389.html
>> (with
>> regard to the question of who the recipient actually is).
>> 
>> You point out another aspect that is not discussed in RFC 
>4119, namely 
>> what is the relationship between retransmission-allowed and the 
>> policies referenced by the ruleset-reference element. RFC 4119 also 
>> does not saw what the meaning is if the ruleset-reference is empty.
>> 
>> Ciao
>> Hannes
>> 
>> >-----Original Message-----
>> >From: [e-mail]
>> >[mailto:[e-mail]] On Behalf Of Thomson, Martin
>> >Sent: 12 March, 2009 08:13
>> >To: GEOPRIV
>> >Subject: [Geopriv] retransmission-allowed is harmful
>> >
>> >I just finished reviewing draft-barnes-geopriv-lo-sec.  I wont get 
>> >those hours back, but it wasn't all in vain.  There's stuff 
>in there 
>> >I'd recommend to all members of the group.
>> >
>> >A thought arises:
>> >
>> >If I set retransmission-allowed = false, all I'm saying is the 
>> >default.  We knew that already, no gain to be had unless a value of 
>> >true turns out to be useful.
>> >
>> >If I set retransmission-allowed = true, then there are two options:
>> >
>> > (1) the information is totally public - share with the world
>> >
>> > (2) there is an authorization policy that governs 
>redistribution of 
>> >this information
>> >
>> >But that's the thing.  Unless you have a policy, you should be 
>> >assuming the empty policy - and the empty policy prevents 
>> >redistribution.
>> >
>> >Therefore, you need a policy before you can redistribute location 
>> >information.  Therefore, the authorization necessary to 
>distribute is 
>> >signified by the presence of policy.  Absence of policy indicates 
>> >that you should keep the information to yourself.  Therefore, 
>> >retransmission-allowed is pointless.
>> >Therefore, it's harmful because recipients might assume (1).
>> >
>> >The prosecution rests ma'am.
>> >
>> >Cheers,
>> >Martin
>> >
>> >p.s. "is harmful" in the subject was chosen to be inflammatory, if 
>> >you are reading this, I've been successful.
>> >Thank you for your time.
>> >
>> >
>> >---------------------------------------------------------------
>> >---------------------------------
>> >This message is for the designated recipient only and may contain 
>> >privileged, proprietary, or otherwise private information.
>> >If you have received it in error, please notify the sender 
>> >immediately and delete the original.  Any unauthorized use of this 
>> >email is prohibited.
>> >---------------------------------------------------------------
>> >---------------------------------
>> >[mf2]
>> >_______________________________________________
>> >Geopriv mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/geopriv
>> >
>> 
>
>---------------------------------------------------------------
>---------------------------------
>This message is for the designated recipient only and may 
>contain privileged, proprietary, or otherwise private information.  
>If you have received it in error, please notify the sender 
>immediately and delete the original.  Any unauthorized use of 
>this email is prohibited.
>---------------------------------------------------------------
>---------------------------------
>[mf2]
>