[rssac-caucus] Revised proposal for updating RSSAC-002
Wessels, Duane
dwessels at verisign.com
Mon Nov 9 23:06:38 UTC 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.
More information about the rssac-caucus
mailing list