Re: [tor-bugs] #5651 [Metrics Utilities]: Annotation header with descriptor types

["Tor Bug Tracker & Wiki" <torproject-admin@xxxxxxxxxxxxxx>]

#5651: Annotation header with descriptor types
-------------------------------+--------------------------------------------
 Reporter:  atagar             |          Owner:     
     Type:  enhancement        |         Status:  new
 Priority:  normal             |      Milestone:     
Component:  Metrics Utilities  |        Version:     
 Keywords:                     |         Parent:     
   Points:                     |   Actualpoints:     
-------------------------------+--------------------------------------------

Comment(by atagar):

 > For cases 1 to 3 we already have enough context to know what descriptor
 type and version to expect

 That assumes that these files will always be, say, v3 server descriptors?
 Might they be v2 server descriptors in old versions? Or v4 in the future?

 > for 3), we can derive what descriptors are contained in a cached-* file
 from the filename---it's a hack anyway, because Tor's cached-* files are
 highly implementation-specific and we're messing with them on our own risk

 Yes, it's a hack and reading directly from the data directory is
 completely unsupported by tor. However, I think that this is a bad idea
 and not really necessary.

 If tor supported, say, "The data directory *may* contain descriptor data,
 identifiable by the first line of its contents." then some use cases will
 no longer require an open control port at all and tor hasn't painted
 itself into a corner in terms of future changes.

 > We also shouldn't mimic Tor's annotation syntax: let's start metrics
 annotations with "# " instead of "@type".

 Could, though mimicking annotations would make sense if we planned to
 leave the door open for including this with cached descriptors later.

 > For example: leaving the original bridge nickname in sanitized
 descriptors instead of "Unnamed" is a minor change (#5684)

 I've been watching that ticket with some interest since it actually does
 impact stem's parser. On reflection I shouldn't validate bridge scrubbing
 by default - I should move it to an 'is_scrubbed()' method instead...

 > The rule would be that we wouldn't parse a descriptor with unknown type
 or higher major version than ours, but that we would parse a descriptor
 with higher minor version, possibly emitting a warning.

 Sounds good

 > # server-descriptor 1.0

 Shouldn't this be "server-descriptor-3 1.0"?

 Cheers! -Damian

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