Re: [ogpx] VWRAP Draft Charter - 2009 09 01

[Carlo Wood <[e-mail]>]

Nobody reacted to this post of me so far,
does that mean everyone agrees?

On Fri, Oct 02, 2009 at 03:23:35AM +0200, Carlo Wood wrote:
> On Thu, Oct 01, 2009 at 06:25:22PM -0400, David W Levine wrote:
> > We need to be careful, when looking at this stuff to strike a balance between
> > focusing on the current deployed clusterings, and turning everything into soup.
> > That said, the actual deployed systems which implement these specifications are
> > only going to be able
> > to enforce policy at the interfaces we define, and these interfaces are on
> > services, not domains.
> 
> It is because we can't allow *every* possible deployment to be supported (soup)
> that I brought up my worries about which service should determine policy (ToS).
> 
> It would be easy to choose a simplification (== not allow every possibility)
> that leaves out a deployment that is essential, imho.
> 
> My proposal was this:
> 
> The AD can only allow a user to connect to (teleport to) a region (domain)
> or not. If it allows a user to teleport there, then everything that that
> domain allows is allowed.
> 
> I probably should have been more clear about this from the beginning:
> this (my concern) has everything to do with where Abuse Reports go to:
> Once a user is in a given region and breaks a policy (or not) and someone
> else wants to report this user, then the only authority that this report
> should go to is the administration of the region (personally, I even
> advocate the sim, but alas).
> 
> If to whomever an 'abuse report' goes has nothing to do with VWRAP
> than we can skip this topic; but I think it might be relevant and it
> is certainly something we need to keep in mind while designing the
> protocol (to make sure that won't go wrong).
> 
> Example:
> 
> Region RD1 runs on servers in country X whose laws state that adult
> content may be accessed at the age of 16 or older. However, the
> administration of RD1 has it in their ToS that one has to be 18.
> They do not see a reason to ban people of age 16 or 17 however.
> 
> Agentd AD2 is seated in another country where one has to be 21 before
> one is allowed to access adult content.  AD2 does age verification.
> 
> If a person of age 18 logs in with AD2 and tries to TP to RD1 then
> * AD2 may disallow that if they so choose.
> * If AD2 allows the TP, than the user is allowed to access adult
>   content by the ToS of RD1 if their age is 18 or older.
> 
> If the user lives in a country where 18 is old enough as well,
> than I don't think that it matters (legally) where the AD2 is
> seated: the administration of AD2 cannot be sued for allowing
> a person to teleport to RD1 (I hope :p).
> 
> ***************************************************************
> * Hence, it is possible to apply the simplication:            *
> *- AD policies ONLY come into play at the moment of teleport  *
> *  (allow or not).                                            *
> *- Once arrived in a new region, the policies of the AD can   *
> *  be 'forgotten' and only the policies of the RD apply.      *
> *  If the AD doesn't want that, they shouldn't allow the TP.  *
> ***************************************************************
> 
> We shouldn't take this simplification (or deployment limitation) too
> lightly, but I think it is one that will work VERY well in practice
> and well worth it, as it's benefits will far outweight the disadvantages,
> imho.
> 
> If anyone can think of a clear counter example where a TP should
> be allowed but still the AD ToS should determine what is allowed
> and what not, please let us know.
> 
> A clear advantage of this simplification is that it makes
> it trivial where an Abuse Report would go to: namely the to the
> administration of the Region (domain).
> 
> A clear disadvantage of NOT making this simplification is that
> it would be totally unclear where Abuse Reports have to go, and
> that lots of confusion will arise about who can do what and why
> they can and you not.
> 
> -- 
> Carlo Wood <[e-mail]>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx

-- 
Carlo Wood <[e-mail]>