Re: [Geopriv] retransmission-allowed is harmful

["Thomson, Martin" <[e-mail]>]

a) no need to move them, the ruleset-reference is actually pretty good.  Reading lo-sec, I'm thinking that the function this provides (authorizing a rule maker) is useful.  However, this assumes that the use case is valid...not something I've really thought about all that much - how often does one pass information to someone then give them instructions on how they share that - usually, it's enough to indicate that the information is secret rather than trusting someone else to manage dissemination.

b) There's no need to move policy around with it - this is really just a rehash of the discussion on whether we need to indicate that the location URI follows possession model or not.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]]
> Sent: Saturday, 14 March 2009 5:23 AM
> To: Thomson, Martin; 'GEOPRIV'
> Subject: RE: [Geopriv] retransmission-allowed is harmful
> 
> 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]
> >
> 

------------------------------------------------------------------------------------------------
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]