The RSSAC Caucus met about a week ago in Yokohama. During that meeting we discussed some proposed edits to RSSAC-002. I had written previously about this with a proposal to include TCP's extra two octets in the size calculations. However, in Yokohama we came to agreement that the two octets should be excluded. I was tasked with submitting a revised proposal for RSSAC-002 updates. Additionally, around the same time, Bruce Crabill sent a message to the list with some additional points of clarification based on his implementation experience. In my revised proposal below I'm also including three items that Bruce raised. If the Caucus agrees with the proposed remedies below I would be happy to present them at the next RSSAC exec call (Thursday Nov 12). DW -------------------------------------------------------------------------------------------------------- Six editorial/clarification problems have been identified in the RSSAC-002 document published November 20, 2014. #1 YAML Indentation =================== Problem: In sections 4.3 (traffic-volume) and 4.6 (unique-sources) the example YAML shows some lines indented when they should not be. In these YAML documents none of the lines should be indented. If they are indented as given in the example, a YAML parser generates an error and fails to load the document. Proposed Remedy: Remove indentation from the example YAML documents in sections 4.3 and 4.6. #2 TCP Response Size ==================== Problem: Section 2.4 describes the query and response size distributions. The description does not specifically mention the two-octet prefix for TCP messages, which leads to ambiguity. While the difference is not especially significant (i.e. two octets out of 50-500), the ambiguity should be removed. The text currently says: DNS query sizes are determined by the length of the entire DNS message. Thus, in practical terms, the transport headers (Ethernet, IP, and TCP or UDP etc) are removed leaving the DNS payload to measure. The DNS query message sizes should be recorded for both TCP and UDP. Proposed Remedy: Insert the following new paragraph immediately following the paragraph quoted above: A DNS message carried over TCP is prefixed with a 16-bit (two octet) value indicating the size of the message. Implementations should exclude these two octets in the calculation of message size. [The RSSAC Caucus debated whether or not to include these two octets in the size calculation. While some argued for its inclusion and others argued for its exclusion, there was strong agreement that consistency is more important than whether or not to count the two extra octets. In the end the Caucus agreed to exclude the size prefix.] The bracketed text could either be written as a footnote or remain in the document body (without brackets). #3 Zone Size Metric =================== Problem: Section 2.2 describes how to calculate the zone size as a wire-format AXFR response. Since AXFR happens only over TCP, those DNS messages also have a two-octet length prefix. The description is unclear whether or not to include the two-octet length prefix in the reported value. Proposed Remedy: Amend the paragraph in section 2.2 to read: The size of the compiled root zone is measured in wire-format AXFR response encoded as if to be transmitted in the smallest number of messages with the names in the zone and the resource records in each RRset sorted into DNSSEC order, and using compression pointers wherever possible. Note that since AXFR occurs over TCP, this measurement must exclude the two-octet size prefix for each message transmitted. #4 Size List Values omit 0-15 ============================= Problem: Section 2.4 describes the query and response size distributions and specifies a list of size ranges. The size range lists begin with 16-31, perhaps under the assumption that 16 octets is the smallest valid DNS message. However, a DNS message with a header only and no RRs is smaller than 16 octets and such have been observed in production traffic. Proposed Remedy: Include 0-15 in the two size lists given for query and response sizes. #5 Quotes Around YAML Keys ========================== Problem: The example YAML documents for load-time (section 4.1) and zone-size (section 4.2) include single quotes around the indented key values. For example: time: '2013082600': 6 '2013082601': 6 These quotes are unnecessary, but accepted by known YAML parsers. The quotes would likely not be generated in the output produced by a YAML library. Proposed Remedy: Remove the single quotes from YAML keys in sections 4.1 and 4.2. #6 'traffic-sizes' format silent on excluding 0 counts ====================================================== Problem: Section 4.5 (rcode-volume) states: Only RCODEs with nonzero counts shall be listed. Section 4.4 (traffic-volume) similarly describes a long list of size values, but does not state that keys with count of zero should be omitted. Proposed Remedy: The following sentence should be added to the paragraph describing traffic-sizes in section 4.4: Only size ranges with nonzero counts shall be listed.