-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/2011 08:26 AM, Cullen Jennings wrote: > > 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.
I'll post a separate response on this, in p2psip only. > > 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. OK, so I'll split the quota algorithm in a separate draft (in the P2PSIP WG) with the same authors list. > > On Jun 6, 2011, at 7:31 PM, Marc Petit-Huguenin wrote: > > 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. - -- 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) iEYEARECAAYFAk3w61kACgkQ9RoMZyVa61cWowCgg9lHq4xRrcdch0PsW2NLmPAI 4dEAn33neMRjBy69CjoG5rD+vQBAuFul =SW6+ -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
