[DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

["Paul Hoffman" <[e-mail]>]

<secretary hat on>

Greetings. The WG has a draft, draft-ietf-dnsop-resolver-priming, which 
has somewhat fallen off the table, and it is time to bring it back. The 
draft has two identified open issues, and the authors would like the WG 
to clear those up before issuing a new draft, and then hopefully going 
to Working Group Last Call. Because the draft is expired, to review it, 
please see:
   https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-05

The two open issues are in Section 4:

4.  Requirements for Root Name Servers and the Root Zone

    The operational requirements for root name servers are described in
    [RFC2870].  This section specifies additional guidance for the
    configuration of and software deployed at the root name servers.

    All DNS root name servers need to be able to provide for all
    addresses of all root name servers.  This can easily achieved by
    keeping all root name server names in a single zone and by making 
all
    root name servers authoritative for that zone.

    If the response packet does not provide for more than 512 octets due
    to lack of EDNS0 support, A RRSets SHOULD be given preference over
    AAAA RRSets when filling the additional section.

    [[Issue 1: EDNS0 is used as an indication of AAAA understanding on
    the side of the client.  What to do with payload sizes indicated by
    EDNS0 that are smaller than 1024, is open to discussion.  At the 
time
    of writing, some root name servers will fill the additional section
    with all available A RRSets, only adding some AAAA RRSets, when
    queried over IPv4 without EDNS0.  Other servers will deliver more
    AAAA RRSets, therefore withholding some A RRSets completely
    [RFC4472].]]

    To ensure equal availability the A and AAAA RRSets for the root name
    servers' names SHOULD have identical TTL values at the authoritative
    source.

    [[Issue 2: Do the TTLs for the root NS RRSet and address RRSets in
    the root and the ROOT-SERVERS.NET. zones need to be aligned?  In 
real
    life responses, the address RRSet's TTL values vary by name server
    implementation.  Is this diversity we can live with?  Should the
    authoritative source prevail?  Is it therefore a protocol issue
    rather than an operational choice of parameters?]]

The question at this point is: what should we do about each issue? 
Specific wording is appreciated.

--Paul Hoffman