November 2015 - rssac-caucus

[rssac-caucus] FOR REVIEW: DRAFT RSSAC002 Version 2
by Steve Sheng Dec. 4, 2015

Dec. 4, 2015

Dear RSSAC Caucus, Attached please find RSSAC002 version 2 for your review. In this version, we made the following changes based on the RSSAC caucus discussions led by Duane: * Section 2.2 (The size of the overall root zone) was amended to clarify that TCP size prefix octets are not included in the metric. * Section 2.4 (The query and response size distribution) was amended to clarify that TCP size prefix octets are not included in these metrics. * Section 2.4 was amended to include 0-15 in size ranges to be tabulated. * Superfluous quotes around YAML keys were removed from example YAML in sections 4.1 (The ‘load-time’ Metric) and 4.2 (The ‘zone-size’ Metric). * Indentation was fixed for example YAML in sections 4.3 (The ‘traffic-volume’ Metric) and 4.6 (The ‘unique-sources’ Metric). * Section 4.5 (The ‘rcode-volume’ Metric) was amended to clarify that nonzero counts should be omitted. In addition, we made the following organizational changes: * Make this document RSSAC002 version 2 * Added a Revision History section (see section 7). Attached please find the redline, clean word and PDF version. Since the proposed revisions have already been discussed and agreed on the caucus list, we will give this update a 7 day additional review period. Please provide your feedback, if any, no later than 23 November 2015. After that, this document will be sent to RSSAC for formal action. Best, Steve

10 17

Re: [rssac-caucus] FOR REVIEW: DRAFT RSSAC002 Version 2
by Kash, Howard M CIV USARMY RDECOM ARL (US) Nov. 19, 2015

Nov. 19, 2015

> > Section 2.1, second paragraph - "may present as anomalies in measurements", > > perhaps change to "may introduce anomalies"? > > How would you feel about "may appear as anomalies"? To me "introduce" > sounds just a little too much like blaming anycast for causing a problem. Or > maybe since this is the same section as the above item, it will likely all > get rewritten in v3 so we save it until then? Either is fine, or "may be present as anomalies", or "may present anomalies". The phrase "present as anomalies" just doesn't parse for me. Howard

1 0

[rssac-caucus] On versioning our documents
by Paul Hoffman Nov. 17, 2015

Nov. 17, 2015

Greetings. This might sound really weenie, but it turns out to be important in the long run. I propose that from now on, we alway publish our documents as "RSSAC 0xx version 1". It is impossible to predict when will or will not need a version 2 (and beyond). If someone says "see RSSAC 0xx", that should always mean "the highest version number of 0xx", not "exactly the one numbered 0xx". The issues in 002 version 2 are not that big but NIST (the US government standards department that creates cryptographic standards) has had *huge* headaches when they have published revisions because Google still refers to the base version, not the most recent one. --Paul Hoffman

3 2

[rssac-caucus] Welcome Two New Members
by Carlos Reyes Nov. 16, 2015

Nov. 16, 2015

Dear RSSAC Caucus, At its meetings on 12 November, the RSSAC approved the Membership Committee's recommendation of two new Caucus members: * Roy Arends * Ondrej Sury They have been added to this mailing list and are now listed as Caucus members <https://www.icann.org/resources/pages/rssac-caucus-2014-05-06-en> . For you reference, their statements of interest <https://community.icann.org/x/orzhAg> have also been published. Please join me in welcoming them to the Caucus! Best, Carlos Carlos Reyes | Policy Specialist carlos.reyes(a)icann.org | +1 (202) 802-8019 ICANN | Internet Corporation for Assigned Names and Numbers 801 17th Street NW, Suite 400 | Washington, DC 20006

1 0

[rssac-caucus] Revised proposal for updating RSSAC-002
by Wessels, Duane Nov. 12, 2015

Nov. 12, 2015

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.

2 2

[rssac-caucus] Opening RSSAC-002 for revision
by Wessels, Duane Nov. 2, 2015

Nov. 2, 2015

Dear RSSAC Caucus, RSSAC has decided to open the RSSAC-002 "Measurements of the Root Server System" document for revision and is asking the Caucus to produce an update. Based on implementation experience, three minor problems have been identified in the current document. It is my belief that these problems and remedies are simple enough that a work party is not warranted. I'd like to ask the Caucus to consider my descriptions of the problems and proposed remedies below as a starting point for this discussion. If we can come to a consensus by RSSAC's December 3 meeting then it is likely the revised document can be approved and published shortly after that. Duane W. #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: Amend the paragraph above to read: 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. For TCP the DNS payload also includes a two-octet size prefix. Implementations should include these two octets in the calculation of message size. #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 also include the two-octet size prefix for each message transmitted.

8 21