Fellow caucus members: There is an RSS Metrics work party call scheduled for tomorrow. I've been adding to and editing the draft document and wanted to bring a few particular items to your attention before the call. Measurement vs Metric. In the terminology section we have some definitions for Measurement and Metric, and a number of comments about whether or not these are the right definitions. I understand that the definition of Metric may not be perfect, but I feel as though we don't have anything better yet. For now these comments are unresolved and AFAIK their usage throughout the document matches their definitions. RSOs. There were a number of comments about "RSO" versus Root Server, versus other ideas (identity, entry point, etc). In my opinion just "Root Server" is the best choice so far, so I went ahead and changed most occurrences of RSO to Root Server. Measurement Intervals. I spent some time thinking about measurement intervals and also read through the April meeting transcripts. I think there is value in giving all metrics the same measurement intervals. It would be much simpler. Whereas previously some measurements were specified at one minute intervals, I think, and based on the transcripts, five minutes would be fine. I'd like to propose five minutes for most measurements. Aggregation Intervals. On the one hand I think it could be useful to define metrics in such a way that they can be used for any aggregation interval, from hours to days to months. On the other hand, it is simpler to just define consistent aggregation intervals for all metrics. I think one day would make a good aggregation interval for all metrics. PTI Naming Performance Reports. During the April meeting with RSSAC we looked at the PTI performance reports for examples. You can find them at https://www.iana.org/performance/csc-reports. There are some things that I think the PTI reports do very nicely, and I've added some examples of how the RSS metrics might look in the PTI report style. Platform and Probe Locations. Thus far we've been imagining that measurement probes are sort of widely distributed and located on third-party networks. One difficulty with this approach is that third-party networks are perhaps susceptible to interception, spoofing, and so on. Also we've spent some time talking about the difficulty of getting meaningful latency measurements over third-party networks that are out of the operator's control. I would like to have a discussion where we might consider probes located closer to the root servers to eliminate some of those uncertainties. Random Query Names. For some metrics I think we have a need to send queries for non-existent names. At one point I proposed using reserved TLDs (.localhost, .invalid, etc). I also have a proposal to use a randomly generated query name in the form of a single letter followed by some number of digits. See RAND-NXD in the document. DW