Opened 4 years ago

Last modified 23 months ago

#17861 assigned enhancement

Consider adding a new interface RelayNetworkStatusMicrodescConsensus

Reported by: karsten Owned by: metrics-team
Priority: Low Milestone:
Component: Metrics/Library Version:
Severity: Normal Keywords: metrics-2018
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (7)

comment:1 Changed 3 years ago by iwakeh

Milestone: metrics-lib 2.0.0

This should be considered when working on #19640.

comment:2 Changed 3 years ago by iwakeh

Milestone: metrics-lib 2.0.0metrics-lib 1.9.0

comment:3 Changed 2 years ago by iwakeh

Owner: changed from karsten to iwakeh
Status: newaccepted

Taking this on together with #19640.

comment:4 Changed 2 years ago by karsten

Milestone: metrics-lib 1.9.0

We decided today not to let this ticket (and #19640) delay the 1.9.0 release, and 2.0.0 won't be a good target milestone either. Taking this out of planned milestones for now.

comment:5 Changed 2 years ago by karsten

Keywords: metrics-2018 added

comment:6 Changed 2 years ago by iwakeh

Be aware of #24028 when starting to work on this task.

comment:7 Changed 23 months ago by iwakeh

Owner: changed from iwakeh to metrics-team
Status: acceptedassigned

Move to metrics-team as these are not worked on by me during the next week.

Note: See TracTickets for help on using tickets.