[tor-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 tor-bugs
mailing list