[rssac-caucus] Revised proposal for updating RSSAC-002

[Wessels, Duane]

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.