[metrics-bugs] #28615 [Metrics/Library]: Additional @type annotation

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Nov 28 22:50:46 UTC 2018


#28615: Additional @type annotation
-----------------------------+------------------------------
 Reporter:  atagar           |          Owner:  metrics-team
     Type:  enhancement      |         Status:  new
 Priority:  Medium           |      Milestone:
Component:  Metrics/Library  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:                   |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------

Comment (by atagar):

 > Adding a @type annotation for detached signatures sounds reasonable.

 Great! Thanks Karsten. Once the @type docs are updated please let me know
 and I'll make the related tweaks on stem's end.

 > But I'm less clear about the other three

 You're completely right that router status entries are simply entities in
 a network status document (**@type network-status-***). The trouble is
 that unlike other descriptor types router status entries are often
 provided on their own. For example, via the control port...

 {{{
 >>> GETINFO ns/name/caersidi
 250+ns/name/caersidi=
 r caersidi O7NMYwctnRDoNu5ClocT97kyX2Y 1cL1nVzDsMuGliTcNUnjIc6MAEE
 2018-11-26 17:23:54 208.113.135.162 1443 1444
 s Fast Guard HSDir Running Stable V2Dir Valid
 w Bandwidth=4820
 .
 250 OK
 }}}

 As such stem users sometimes have a desire to parse individual router
 status entries despite the fact that they're not technically valid
 descriptors on their own.

 > why would we not do the same with dir-source entries

 That's an interesting point. Is there anything that vends dir-source
 entries on their own?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28615#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the metrics-bugs mailing list