[tor-bugs] #17861 [metrics-lib]: Consider adding a new interface RelayNetworkStatusMicrodescConsensus

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17861: Consider adding a new interface RelayNetworkStatusMicrodescConsensus
-----------------------------+---------------------
     Reporter:  karsten      |      Owner:  karsten
         Type:  enhancement  |     Status:  new
     Priority:  Low          |  Milestone:
    Component:  metrics-lib  |    Version:
     Severity:  Normal       |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |    Sponsor:
-----------------------------+---------------------
 There are currently three different version 3 network status document
 types, identified by the following `@type` annotations:
  1. `@type network-status-vote-3 1.0`: these are votes exchanged by
 directory authorities;
  2. `@type network-status-consensus-3 1.0`: these are (unflavored)
 consensuses based on votes and published by directory authorities;
  3. `@type network-status-microdesc-consensus-3 1.0`: these are the same
 consensuses as before but using a specific flavor, in this case one that
 references microdescriptors rather than server descriptors.

 So, while we're using a separate interface for the first type
 (`RelayNetworkStatusVote`), we're using the same interface
 (`RelayNetworkStatusConsensus`) for the second and third type.  This only
 works, because the only differences between unflavored and microdesc-
 flavored consensuses can be found in the network status entries, and we're
 using the generic `NetworkStatusEntry` for those.  But as soon as there
 will be new keywords in either unflavored or microdesc-flavored
 consensuses, we'll have to add support for them to
 `RelayNetworkStatusConsensus`, even though the other flavor doesn't
 support them.

 We might consider adding another interface
 `RelayNetworkStatusMicrodescConsensus` for microdesc-flavored consensus,
 which would probably just extend `RelayNetworkStatusConsensus` for now (or
 copy over everything from it? uhhh).  But if microdesc-flavored
 consensuses ever derive from unflavored consensus in header or footer,
 we'll be able to model those changes correctly.

 Related to this suggestion, we might consider making `NetworkStatusEntry`
 less generic by using a separate `Entry` interface like we just did for
 `ExitList`.  Following that model, `RelayNetworkStatusVote.Entry` would
 keep its `getMicrodescriptorDigests()` method,
 `RelayNetworkStatusConsensus.Entry` would drop that method, and
 `RelayNetworkStatusMicrodescConsensus.Entry` would get a
 `getMicrodescriptorDigest()` (singular) method.

 I don't think these changes are super urgent, but I wanted to write them
 down before resolving #17000 where they first came up.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17861>
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