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

[Suzanne Woolf <[e-mail]>]

Joe,

Thanks for laying this out.

All,

Joe’s correct here. 2870bis obsoletes 2870, quite deliberately. (http://datatracker.ietf.org/doc/draft-iab-2870bis/ <http://datatracker.ietf.org/doc/draft-iab-2870bis/>, it’s not long.) And RSSAC 001 (https://www.icann.org/en/system/files/files/rssac-001-draft-02may13-en.pdf, which is marked “draft” because it’s waiting on 2870bis) discusses resource expectations and other operational requirements.

The scoping issue Joe points out wasn’t immediately obvious when I re-read resolver-priming after not looking at it for awhile, but times have changed since it was written; 2870bis came about partly because there are now places and mechanisms for ICANN and RSSAC to publish their own information about what ICANN and the root server operators actually do.

Can we refocus specifically on what the DNS protocol requires in priming queries and responses for them to serve the purpose, and where it might be silent or ambiguous? Assumptions about operational factors such as resource constraints need to be clearly separated from protocol-level analysis.


thanks
Suzanne


> On Oct 16, 2015, at 10:27 AM, Joe Abley <[e-mail]> wrote:
> 
> 
> 
> On 15 Oct 2015, at 20:06, Paul Hoffman wrote:
> 
>> The two open issues are in Section 4:
>> 
>> 4.  Requirements for Root Name Servers and the Root Zone
> 
> I think it might be worth stepping up a level here and understanding what this document can reasonably specify.
> 
> 2870 has long been recognised to be obsolete. The direction for fixing that (which, who knows, might actually result in action at some point) can be summarised as the union of draft-iab-2870bis (currently approved for BCP, sitting in the RFC Editor queue) and RSSAC-001 (currently waiting for 2870bis to be published).
> 
> The approach being taken is that the IETF provides protocol-level requirements, and RSSAC documents the operational expectations that are reasonable to have of root server operators.
> 
> Analogously, and relevant to this document, the contents of the root zone, the names of root servers, and the operational practicalities of the ROOT-SERVERS.NET zone (contents, and where it is hosted) are currently managed by the IANA Functions Operator under contract. RSSAC is currently working on analysis and advice to ICANN on the question of whether the current naming scheme could be improved upon.
> 
> This document, I believe, needs some revision to make sure it stays on the right side of the line between technical policy (from the IETF), administrative policy (from the IANA Functions Operator) and operational policy (from the root server operators, as documented by RSSAC).
> 
> So, for example:
> 
>> 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.
> 
> I think this document needs to be clear that the requirements it is imposing on the system as a whole are protocol-level requirements, and not operational or administrative.
> 
> I am deliberately not suggesting edits to the current text or responding to the two issues you highlighted in this message; I think it's important to get consensus first about the scope of guidance that this document can provide.
> 
> To be clear, I think it's important and necessary that the priming process be documented; I just think we need to be careful that we do it from a protocol perspective.
> 
> 
> Joe
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop