Re: [tor-bugs] #3038 [Tor Directory Authority]: Update dir-spec.txt with microdesc, consensus-flavor info

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#3038: Update dir-spec.txt with microdesc, consensus-flavor info
-------------------------------------+--------------------------------------
 Reporter:  nickm                    |          Owner:  nickm             
     Type:  defect                   |         Status:  needs_review      
 Priority:  major                    |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Directory Authority  |        Version:                    
 Keywords:                           |         Parent:  #4933             
   Points:                           |   Actualpoints:                    
-------------------------------------+--------------------------------------
Changes (by karsten):

  * status:  needs_revision => needs_review


Comment:

 Replying to [comment:6 nickm]:
 >  * It is not a requirement that microdescs be a transform only of the
 routerdesc; they could also someday include authority-generated info.

 Right.  In fact, they already contain authority-generated info: the exit-
 policy summary.  I changed the first sentence in 3.2.

 >  * Clients don't need identity keys; they still have identity
 fingerprints from the consensus.  This lets them correctly make extend
 cells, and recognize that they've corrected to the right first hop with
 their entry nodes.  I should add something to talk about the security
 model here.

 Yes, I think that would be quite useful.

 >   * No need to include downside and discussions in spec; that's what
 proposals are for.  Likewise with design suggestions in 4.5.

 Do you mean my comments in brackets?  These mostly contain questions to
 you when reviewing my patch.  Please feel free to remove them if you think
 they should go away.

 Or do you mean other mentions of downsides or design decisions?  I tried
 to reduce those to the absolute minimum.  Like, I found it helpful to
 leave a sentence in that says that creating too many flavors is bad.
 Please remove anything that you think is too much design.

 >   * Consensus flavors are not "consensus-like documents": They are
 consensuses! Regular consensuses have the "ns" flavor.  The "microdesc"
 consensus flavor also exists.  It is false to say that their format is as
 yet unspecified.  Must rewrite 3.6.

 I changed the phrasing to say that they're variants of the unflavored
 consensus.  I also added a new Section 3.6.1 for the ns consensus flavor.

 >  *  Some of the general language is not really spec-language. A spec is
 about saying what the system _must_ do in order to be correct; or what it
 _should_ do to perform well; or so on.  Sections 3.6 and 3.6.1 have this
 problem.

 Hmm, I'm not good at spec language.  Would you mind fixing the language
 where it should be more spec-like?

 >    * Section 3.8 needs to go away; it is not implemented.  As does the
 "an authority further makes the consensus index available at" part later
 on.  As does the part about "Directory caches also fetch the consensus
 index" later on.  We do not merge stuff into the spec if it isn't
 implemented.

 Right.  I removed the spec parts mentioning the consensus index in a
 single patch.  Should I create a new Trac ticket for implementing the
 consensus index and attach the patch there?

 What about `/tor/micro/all[.z]` which is not implemented, either?

 I'm attaching a tarball containing three patches:

  - 0001.. is equivalent to the previous patch, except for some Git meta
 data.  Content is the same.
  - 0002.. removes the consensus index parts.
  - 0003.. contains the changes as as mentioned in this comment.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3038#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs