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):

 > Minor nitpick: they have always been v1 server descriptors, not v3

 Ohh, in that case I've misnamed stem's classes for it...
 https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/descriptor/server_descriptor.py#l1

 > What I'd expect is that there'd be a new command or URL to give you the
 v2 server descriptor.

 Right, that's essentially what microdescriptors are I think.

 > The downside, though, is that Tor will create an interface that it may
 support.

 Yup. On second thought you're right that tor shouldn't vend its data
 directory's descriptors. However, since they're around anyway (and not
 likely to go away any time soon) I still think that making this part of
 the cached files would be helpful.

 > Yeah, the scrubbing method isn't set in stone.

 When it changes do you re-publish old bridge descriptors with the new
 scheme or are there a variety of scrubbing schemes floating around? My
 parser will need to change when scrubbing changes are invalid according to
 the dir-spec. For instance if we drop a mandatory field (like we did for
 onion-key and such) then we'll need to update...
 https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/descriptor/server_descriptor.py#l776

 Oh well, that's why I made it a separate subclass.

 > And some time ago we added the 10.x.x.x thing for IP addresses instead
 of the 127.0.0.1 as it was before.

 If there's descriptors around with the old address then I have an issue
 since my parser relies on the first line having a 'router Unnamed 10.'
 prefix to figure out if it's a bridge descriptor or not. Oh well, that's
 what this ticket will be solving. :)

 If the old scrubbing scheme is still around then I'll check for a 'router
 Unnamed 127.0.0.1' prefix too.

 > Should we ask Nick and Roger what they think about including @type
 annotations in descriptors returned by the control port, dir port, and/or
 included in cached-* files?

 Annotations currently only appear in cached descriptors, not via the
 control or dir port. They don't need the @type header since the caller
 knows what they're requesting, and including it would likely confuse and
 break callers.

 The cached descriptors is all that I would like to change in tor. And yup,
 we should ask for input from them next.

 > And should I specify the annotations for files in metrics tarballs
 somewhere on metrics.tpo and start including them in the existing
 tarballs? Or is there anything we overlooked?

 Sounds good to me but lets first get Nick's opinion before proceeding.

 Cheers! -Damian

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