On 1/6/14 9:22 PM, Damian Johnson wrote:
I'm not sure what you mean by "specialized DirPort method". Can you explain that in more detail?
No doubt I'm missing something basic about either the problem we're trying to solve or how votes work. :P
What I meant by a "specialized DirPort method" was the methods in section 4.2 ('/tor/status-vote/current/consensus' and friends). My rough guess from the proposal is that the trouble is...
- A new relay publishes their descriptor to a single authority. (?)
- The authority communicates the new descriptor to the rest via their
v2 document. 3. Authorities now have an enumeration of all relays, and generate their vote.
... and we don't want #2 to use v2 documents. If that's the case then the simple solution seems to be something like...
- When an authority receives a descriptor it forwards it to all the
other authorities.
That approach scales a lot less than exchanging a single status opinion document once per voting period.
My understanding is that votes don't need to precisely match. If a descriptor comes in during the window where votes take place then that's fine - the majority of authorities won't have it and it simply won't be included until the following consensus.
That's correct. The question is whether we want to fix the situation that it might take until the next consensus to include a relay that could have been included in the current consensus.
See also Nick's comment on the other proposal 147 review thread:
Also, ISTR that Roger told me that this whole proposal didn't actually seem to be necessary in practice. I wish I could remember the rationale, though.
Personally, I don't feel strongly about either adding prevoting opinions or living with the 1-hour delay in edge cases. But the current situation where we keep publishing v2 statuses is not ideal.
All the best, Karsten