Hi Nick. Thanks for the comments!<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">* IN_TYPE/OUT_TYPE talk about the type of an inbound/outbound<br>

&quot;connection.&quot;  Do you mean circuits, or connections on the circuits?<br>
Either way I&#39;m confused.  For example, a control connection is never<br>
attached to a circuit at all.<br></blockquote><br>Yea, that isn&#39;t really appropriate and was making the spec messier than it needed to be. Replaced with a single TYPE parameter to indicate the placement in the circuit (guard/bridge, relay, exit, or one-hop in case they&#39;re allowing them).<br>
<br>This was a bad attempt to shoehorn certain connection information I thought would be interesting, such as:<br>- control connections<br>- client circuits<br>- directory mirroring<br>

- hidden service hosting<br><br>so users could tell the bandwidth usage on these sorts of connections. However, while interesting this really has nothing to do with acting as a relay, so dropped. Oh well... maybe in another proposal some day...<br>
<br>Dropped the split from the bandwidth measurements too so they&#39;re simpler. Also, do you think something like this notice...<br>&quot;These represent logical circuits, not necessarily network resources (which might be shared between circuits via connection multiplexing).&quot;<br>
would help, or not?<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">* The spec addition isn&#39;t clear whether we mean all circuits, OR<br>

circuits, or what.  I believe it&#39;s &quot;all circuits&quot;, but it should say<br>
so.<br></blockquote><br>The &quot;circ/all&quot; entry already said &quot;all current circuits&quot; so I&#39;m guessing you meant the inclusiveness of &quot;circ/id/*&quot;. Added &#39;relay&#39; to the description, but I&#39;m not quite sure what sort of clarification you&#39;re looking for here.<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* IN_TYPE/OUT_TYPE are specified as being an empty string if there are<br>
no connections.  That&#39;s kind of fragile for parsing, since it would<br>
mean that users could no longer fold multiple spaces into one like<br>
they can for all the other control protocol formats .<br></blockquote><br>No longer relevant with the changes above.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* There&#39;s nothing specifying that &quot;all&quot; is not a valid identifier, so<br>
&quot;circ/all&quot; is ambiguous. To be consistent with the rest of the getinfo<br>
formats, let&#39;s say that the GETINFO key for a single circuit is<br>
circ/id/&lt;circid&gt;, and the GETINFO for all circuits is circ/all.<br></blockquote><br>Good point! Changed. Also specified that the circuit ID is numeric.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* You clarified in your email that circ/all is a list of data in the<br>
form given by circ/&lt;ID&gt; , but you didn&#39;t make that clarification in<br>
your spec.<br></blockquote><br>Changed (not sure about the wording though...).<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">* There&#39;s no way to get notifications about new OR circuits, so any<br>

program that wants to keep track of OR circuit state will need to<br>
repeatedly poll circ/all.  Won&#39;t that be expensive on a busy server?<br>
You wouldn&#39;t want to do it, say, once-per-second.  For consistency<br>
with the rest of the controller protocol, OR circuit state changes<br>
would probably want to be some kind of event.<br></blockquote>
<br>Very good idea! Added an update parameter to entries so staleness can be tracked. Also added an event for updates to the information.<br><br>Now on to the other proposal...<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">

* By &quot;relay/flags&quot;, what do you mean?  The flags held by the relay in<br>
the current consensus, or something else?<br></blockquote>
<br>Yup. Clarified the entry.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">* On &quot;desc/time&quot;, why is it important to know the latest time we<br>

fetched a server descriptor?<br></blockquote>
<br>There&#39;s some interesting information here such as your relay&#39;s observed
bandwidth. However, there&#39;s no way of telling how stale information provided by the &quot;desc/id/*&quot; is, and since most relays stop fetching descriptors after a time it&#39;s often hideously ancient.<br><br>What I&#39;d really like an option to manually refresh descriptors (both individually and as a batch call), however since I was aiming to keep this proposal limited to GETINFO options it seemed inappropriate. Do you have any thoughts on this sort of functionality? What section of the control-spec would it go under?<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* On &quot;desc/time&quot;, &#39;unix timestamp&#39; is ambiguous; do you mean &#39;a<br>
decimal integer expressing the current time in seconds since the Unix<br>
epoch&#39; or what?  I think the only other places in the control protocol<br>
that express dates do so in ISO8601 format (YYYY-MM-DD HH:MM:SS,<br>
relative to UTC).<br></blockquote>
<br>Ick! Why use that ISO8601 format? Seconds are much simpler and more easily comparable.<br><br>Yes, I meant the decimal integer. Added clarification there and to the other spec.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* On &quot;process/user&quot;, the spec needs to say what you mean by the<br>
&quot;user&quot;.  On Unix, is it a UID or a username?  What is it on windows?<br>
The spec needs to say.  (You can&#39;t just have the controller tell from<br>
context; on Unix at least, every valid decimal UID is also a valid<br>
username.  If process/user tells me &#39;0&#39;, am I running as root, or as a<br>
user named &quot;0&quot;?)<br></blockquote><br>Specified that it&#39;s the username. Doesn&#39;t windows xp on up have users now? If not, it&#39;s an empty string.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* Also on process/user: If you meant &quot;username&quot;, then there  should<br>
indeed be an option to get all the *id stuff discussed upthread.<br></blockquote><br>I&#39;m sure this is a dumb question but... why? I&#39;ve never had use for the numeric uid, let alone the three other varieties Jake mentioned (actually, never heard of them before...). If you can think of use cases in which they&#39;re useful then by all means include them. However, I don&#39;t particularly care about that information.<br>
<br>... that said, I can see the appeal of including them simply for completeness.<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
* Probably the spec needs to clarify that &quot;process/pid&quot; is the pid of<br>
the _main_ Tor process, but that Tor might launch other processes from<br>
time to time and you shouldn&#39;t be surprised if it does.<br></blockquote>
<br>Done. A pox upon the complexities of identifying the damn process...<br><br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">* Is &quot;process/uptime-reset&quot; affected by the SIGNAL command from the<br>

controller?  The spec should  say.<br></blockquote>
<br>Done.<br><br>Thanks again! -Damian<br><br><div class="gmail_quote">On Wed, Jun 23, 2010 at 10:28 AM, Nick Mathewson <span dir="ltr">&lt;<a href="mailto:nickm@freehaven.net">nickm@freehaven.net</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">On Fri, Jun 4, 2010 at 12:10 AM, Damian Johnson &lt;<a href="mailto:atagar1@gmail.com">atagar1@gmail.com</a>&gt; wrote:<br>

&gt; Hi Nick, thanks for the feedback!<br>
<br>
</div>Hi, Damian!  We&#39;re almost there, I think, with just a few points to clarify.<br>
<br>
On xxx-circ-getinfo-option.txt:<br>
<br>
* The spec addition isn&#39;t clear whether we mean all circuits, OR<br>
circuits, or what.  I believe it&#39;s &quot;all circuits&quot;, but it should say<br>
so.<br>
<br>
* IN_TYPE/OUT_TYPE talk about the type of an inbound/outbound<br>
&quot;connection.&quot;  Do you mean circuits, or connections on the circuits?<br>
Either way I&#39;m confused.  For example, a control connection is never<br>
attached to a circuit at all.<br>
<br>
* IN_TYPE/OUT_TYPE are specified as being an empty string if there are<br>
no connections.  That&#39;s kind of fragile for parsing, since it would<br>
mean that users could no longer fold multiple spaces into one like<br>
they can for all the other control protocol formats .<br>
<br>
* There&#39;s nothing specifying that &quot;all&quot; is not a valid identifier, so<br>
&quot;circ/all&quot; is ambiguous. To be consistent with the rest of the getinfo<br>
formats, let&#39;s say that the GETINFO key for a single circuit is<br>
circ/id/&lt;circid&gt;, and the GETINFO for all circuits is circ/all.<br>
<br>
* You clarified in your email that circ/all is a list of data in the<br>
form given by circ/&lt;ID&gt; , but you didn&#39;t make that clarification in<br>
your spec.<br>
<br>
* There&#39;s no way to get notifications about new OR circuits, so any<br>
program that wants to keep track of OR circuit state will need to<br>
repeatedly poll circ/all.  Won&#39;t that be expensive on a busy server?<br>
You wouldn&#39;t want to do it, say, once-per-second.  For consistency<br>
with the rest of the controller protocol, OR circuit state changes<br>
would probably want to be some kind of event.<br>
<br>
<br>
On  xxx-getinfo-option-expansion.txt :<br>
<br>
* By &quot;relay/flags&quot;, what do you mean?  The flags held by the relay in<br>
the current consensus, or something else?<br>
<br>
* On &quot;desc/time&quot;, why is it important to know the latest time we<br>
fetched a server descriptor?<br>
<br>
* On &quot;desc/time&quot;, &#39;unix timestamp&#39; is ambiguous; do you mean &#39;a<br>
decimal integer expressing the current time in seconds since the Unix<br>
epoch&#39; or what?  I think the only other places in the control protocol<br>
that express dates do so in ISO8601 format (YYYY-MM-DD HH:MM:SS,<br>
relative to UTC).<br>
<br>
* On &quot;process/user&quot;, the spec needs to say what you mean by the<br>
&quot;user&quot;.  On Unix, is it a UID or a username?  What is it on windows?<br>
The spec needs to say.  (You can&#39;t just have the controller tell from<br>
context; on Unix at least, every valid decimal UID is also a valid<br>
username.  If process/user tells me &#39;0&#39;, am I running as root, or as a<br>
user named &quot;0&quot;?)<br>
<br>
* Also on process/user: If you meant &quot;username&quot;, then there  should<br>
indeed be an option to get all the *id stuff discussed upthread.<br>
<br>
* Probably the spec needs to clarify that &quot;process/pid&quot; is the pid of<br>
the _main_ Tor process, but that Tor might launch other processes from<br>
time to time and you shouldn&#39;t be surprised if it does.<br>
<br>
* Is &quot;process/uptime-reset&quot; affected by the SIGNAL command from the<br>
controller?  The spec should  say.<br>
<br>
yrs,<br>
--<br>
<font color="#888888">Nick<br>
</font></blockquote></div><br>