[metrics-team] How to establish identity on converted descriptors

[tl]

Hi,

turns out the easiest way to distinguish relays, bridges and the respective extra descriptors from each other is the "digest" value (that so far we haven’t included in the conversion).
After our conversation I realized that I’m not sure if "type + published + fingerprint" can't differentiate between descriptors just as good as "digest"? Problem is I’m not so fond of the idea of integrating the digest value just for the purpose of disambiguation. Since the other descriptors will have to rely on combinations of fields for disambiguation anyway couldn’t we go the same route with relays, bridges and extra descriptors?

There were other changes as well. For relay vote a combination of "type", "identity" and "valid after" guarentees uniqueness. For relay consensus and bridge status "type" and "valid after" is sufficient. Tordnsel/ExitLists can be identified by "type" and "downloaded", Torperf need a combination of "type", "source", "file size" and "start".

So the current state is:

    relay         digest  (or type + published + fingerprint ?)
    bridgeExtra   digest  (or type + published + fingerprint ?)
    relayExtra    digest  (or type + published + fingerprint ?)
    bridge        digest  (or type + published + fingerprint ?)
    relayConsens  type + valid-after
    bridgeStatus  type + valid-after
    relayVote     type + valid-after + identity
    tordnsel      type + downloaded
    torperf       type + source + filesize + start


Cheers,
oma



> On 21.06.2016, at 08:06, Karsten Loesing <karsten at torproject.org> wrote:
> 
> Signed PGP part
> Hi Thomas,
> 
> we briefly talked about identifiers yesterday.  Mind posting the result?
> 
> All the best,
> Karsten
> 
> 
> On 19/06/16 23:01, tl wrote:
> >
> >> On 19.06.2016, at 19:30, tl <tl at rat.io> wrote:
> >>
> >> We were discussing handling of duplicate descriptors during the
> >> last metrics-team IRC chat. Thinking about it I became aware that
> >> I’m not always sure how to establish the identity of a descriptor
> >> in the first place. It’s easy for descriptors that contain
> >> fingerprints (relay, relayExtra, bridge, bridgeExtra). For the
> >> other descriptors I could imagine that certain timesamps can
> >> serve as identifiers. I guess the type information is always
> >> needed as a second part to guarentee uniqueness of the
> >> identifier.
> >>
> >> relay         type + fingerprint relayExtra    type +
> >> fingerprint relayVote     type + published (or valid-after?)
> >> relayCons     type + valid-after bridge        type +
> >> fingerprint bridgeExtra   type + fingerprint bridgeStatus  type +
> >> published torperf       type + start tordnsel      type +
> >> downloaded
> >>
> >> Can soemone please comment if this makes sense?
> >
> >
> > Okay, I can see for myself that it doesn’t. Relays and bridge
> > descriptors additionally need a timestamp to be unique since the
> > fingerprint identifies only the router itself, at any point in
> > time. OTOH vote  descriptors need an authority identifier.
> >
> > relay         type + fingerprint + published relayExtra    type +
> > fingerprint + published relayVote     type + identity + published
> > relayConsens  type + valid-after bridge        type + fingerprint +
> > published bridgeExtra   type + fingerprint + published bridgeStatus
> > type + published torperf       type + start tordnsel      type +
> > downloaded
> >
> > That’s better but is it good enough? BridgeStatus, Torperf and
> > Tordnsel still seem underspecified to me.
> >
> >
> > oma _______________________________________________ metrics-team
> > mailing list metrics-team at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team
> >
> 






< Der Siegeszug der Populisten - http://www.stern.de/6880250.html >
< Diskurs und Wutbürger - http://www.faz.net/aktuell/politik/inland/politik-braucht-eine-sprache-der-maessigung-14281846.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20160621/c7c6d10d/attachment.sig>