On 20 Dec (17:44:31), George Kadianakis wrote: > David Goulet <dgoulet@xxxxxxxxx> writes: > > > On 06 Dec (10:09:57), teor wrote: > >> > >> > On 6 Dec. 2016, at 09:56, David Goulet <dgoulet@xxxxxxxxx> wrote: > >> > > >> > <snip> > >> > > >> > >> Here's a suggested strategy: > >> * at load time, validate the HS options as if v2 is the default, and > >> validate them as if v3 is the default, and fail if either validation > >> fails. > >> * then, act on the HS options as if v2 is the default, and also act as > >> if v3 is the default, and fail if either action fails. > >> (We need to do this because we don't discover some option issues > >> until runtime, such as whether the directory can be created.) > >> * then, when each consensus is downloaded, publish whichever descriptor > >> is the default in the consensus (if the HS config does not specify > >> a specific version). > > > > This is a reasonable way to proceed considering we use a consensus param to > > know which version of default HS to create. I see this as more of an > > engineering problem that can be solved. > > > > Which what I would like us to decide on if we think that consensus param > > controlling the default version is a good idea or not. If we think yes, we can > > pull it off, if not everything is simpler :). > > > > So just to be clear, I'm behind you on the concern of making sure we validate > > the options on launch instead of failing at consensus download. There are ways > > we can address that like you outlined above. > > > > Hello, > > I agree that this is more of an engineering problem that can be > solved. I also like the agility that the consensus parameter gives us. > > That said when we get close to implementing this feature, IMO we should > estimate how long it will take us to implement this consensus parameter > logic, and evaluate whether it's worth doing. This feature might be an > evening of work, but it could also be two annoying weeks of testing and > debugging crazy networking and consensus fetching edge cases, so we > should make sure we don't sign up for too much craziness. > > The alternative would be that we don't do the consensus parameter, and > instead we just change the version parameter in alpha/stable releases > when we feel it's ready. This will be a slower and more gradual > deployment which is not necessarily a terrible thing when we are talking > about huge features like prop224. Agree. In a matter of few hours, we'll know if this is too much engineering with lots of corner case untested or actually doable easily. The fallback to use the parameter is a good idea to avoid going overboard if we realize it is kind of crazy. Cheers! David
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev