I can't put my finger on why, but I get very nervous about suing downloadable 
scripts to enforce critical system constraints such as security and quotas. It 
just seems like a disaster waiting to happen. That said, I can't come up with 
any specific problem of why it would not work but it makes me feel very uneasy. 

It does seems reasonable to make this type of quota a general purpose extension 
to reload that could be used by things beyond vipr WG stuff. 

On Jun 6, 2011, at 7:31 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Now that version -15 of RELOAD is out, I am able to restart editing
> draft-petithuguenin-vipr-reload-usage which is, as its name indicates, a 
> RELOAD
> usage for VIPR.  Most of it can now be implemented with standard RELOAD,
> excepted for one thing, the quota algorithm.
> 
> The quota algorithm in VIPR is interesting because it looks like it can be
> applied to other resources than the one handled by VIPR.  This quota works by
> using a variable that limits, at a responsible peer, the number of resources
> that can be stored by one storing peer.  More precisely, the number of unique
> resource (of one kind) that a storing node can store in one responsible peer 
> is
> the quota value divided by the fraction of resources this peer is responsible
> for (adjusted for the number of replicas and other parameters, but let's 
> forget
> this for now).  The two standard quota parameters in RELOAD only limit the
> absolute number and or size of the resources that can be stored.
> 
> The ideal would be to add the VIPR quota inside the RELOAD base spec. Having
> stuff in base is good because in this case any RELOAD implementation could be
> used for VIPR (or any other overlay), and - in my opinion - having multiple
> implementations of RELOAD inside one overlay is what will help an overlay to
> survive a programmer error.
> 
> Now I would agree that we should stop adding stuff to base, to have a chance 
> to
> see it published as an RFC one day, so perhaps an alternative idea is to do 
> the
> same thing for quotas that I did for access control policy:  Use a script in 
> the
> configuration file to express the quota algorithm associated to a specific 
> Kind-ID.
> 
> Is there any opinions or questions or comments on this?
> 
> Note that this email is cross posted with the VIPR working group, but please
> follow up only in P2PSIP.
> 
> Thanks.
> 
> - -- 
> Marc Petit-Huguenin
> Personal email: [email protected]
> Professional email: [email protected]
> Blog: http://blog.marc.petit-huguenin.org
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk3tf4UACgkQ9RoMZyVa61f0LwCgm4OkWYDf46pZ7GjfPfu93BBJ
> NcUAnAtLP1kTvzZ51F9jTucTUcTp6f9Y
> =kM4T
> -----END PGP SIGNATURE-----
> _______________________________________________
> VIPR mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/vipr

_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to