Hi,

Please find my comments. I found the document very interesting, and pleasant to read.

Regarding Steve's questions, here is my opinions.

1) whether there are any factual errors with the document.

I did not see any factual error.

2) whether you agree with the study methodology and the conclusions that are drawn from these studies

Regarding the methodology, my understanding is that there is an impressive survey of the TTL values used that are related to the one specified in the root zone. In addition to this section I think it would be beneficial to have:
- 1) a description of the impact of the TTL on ICANN operations on the root zone. Such operations may be for example addition/removal of a new gTLD, key roll over, emergency key roll-over - of course, the topic should remain the TTLs.
- 2) a "theoretical" section that details what RFCs recommends for the various TTL settings. From this section I believe we should be able to be able to have a theoretical model, and describe theoretically how TTLs impact the ICANN operations on the root zone as well as the expected impacts on the traffic. I would also see that section 6.4 can fall into such a section.

3) whether you agree with the findings of the report

I agree with the findings. However, saying that the value should not be changed because most client ignore it does not seems satisfactory. First I would say that the boundary seems to be the "max-cache-ttl" value, and having TTL values below it would probably have a major impact. In fact for most of the traffic, max-cache-ttl overwrites the TTL and becomes the de-facto TTL. I think we should elaborate a bit more about has the right TTL value (the root zone or the max-cache-ttl), and see if there are any recommendations to do for the max-cache-ttl value. I also understand it may be out of scope of the root zone TTL, but change of this value probably impact more the root zone traffic than the current TTL.

4) whether you agree with the recommendations in this report

I agree with the recommendations. However, I think we should also comment on the max-cache-ttl. As TTL is related to caching, I also think there should be some additional items on how these caches may be flushed by an authoritative party -- I am really thinking of the red button Joe Abley talked about in case of a emergency key-roll over, but it looks this could be useful in other situations. Maybe we should also see some debugging indications when a badly cached value is stored -- again I am mostly thinking of outdated signatures RRsets cached.

5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?

I also found I couple of nits in the document.

1) introduction: The document uses the term "Internet Community": I am wondering whether this community is identified enough to named as such or if Internet community would be more appropriated.

2) section 3: Types of data in the DNS Root zone:

I think that some clarifications should be made in section 3 regarding the type of data. I found it quite confusing to read that most authoritative data are 1d TTL as most NS have 2d TTLs. This comes from the fact that TLD NS are not part of the authoritative data. I looked at dratf-ietf-dnsop-dns-terminology and checked that whether TLD NS are authoritative data or not is somehow confusing. So I would suggest to explicitly state it. The text I would propose could be something like:

"In this section we considered three types of DNS data.
- authoritative data : the data the root zone has authority for. In our case, we did not consider the TLD NS nor the TLD Glue RRsets (A, AAAA).

- delegation: The definition provided by the terminology section does not fit here as it is not a process.

- glue: (cf terminology section)

Another alternative could also consists in clarifying the usage in the terminology section.

At last is there any need to have a specific terminology for these authoritative RRsets and have it mentioned in the dns-terminology draft ?

3) section 3 "glue TTLs match their associated NS TTLs" I think we should specify whether this is something observed or if this follows some operational guidance.

4) section 3.1 "which means it has a negative caching TTL of 1 day". I think this may impact the publication of gTLD. as well as emergency key-roll over.

5) section 6.1.1

The graph below shows each TLD’s authoritative NS TTL (y-axis) and its query count in the 2014 DITL data (x-axis). While there are certainly a large number of less-popular TLDs with large RTTs, by looking at the lower right section of the graph we can see that the more-popular TLDs tend to have larger RTTs (Round Trip Times). In other words, there are no popular TLDs with small RTTs. Overall, 90% of queries in 2014 DITL data were to TLDs having NS TTLs greater than or equal to 1 day.

I do not see the relation with RTT. Isn't misspelling of TTL?

6) section 6.2 "The authoritative server returns the TXT record without a 10-day TTL." Shouldn't be "with" instead of without?

7) section 6.3 "The study team did find 20% of the IPs made only one request for delegated TLDs during collection . ". Shouldn't it be "data collection period" instead?

idem for "Nearly 20% of the IPs made only request for delegated TLDs during collection".

8) Section 6.3

"IPs sending queries (red line) and providing measurements (blue line)." or the legend Queries/Measures in figure 4 does not make obvious the difference between the two lines. Maybe that would be better to clarify that explicitly.

9) section 6.3 "Figure 6 and Table 8 below shows" Shouldn't it be "show"

10) section 6.4.1/ section 7 Findings 4: lots of missing white space after ".".

11) section 6.4.1 Is there any reason the relation between the different Time is not expressed. SOA_Expire + NS_TTL <= ZSK_validity

12) section 6.4.2 "Just before day 10, a root server instance experiences a problem which prevents the it from receiving zone" Shouldn't we remove "the"?

13) Findings 2:
"This likely means that root zone TTLs could be reduced to 1 day without any significant impact on traffic levels to root name servers"

Is that intentional to repeat the sentence?

14) Findings 6:

"In Section 6.4, the study team identifies two situations whereby a root name server would return data and signatures that will be cached beyond the signature validity end time. Specifically, in certain situations: "

Do we have any kind of formal proof that there is no other corner cases.

15) section 9:
Don't we need DNSSEC mitigation mechanisms to flush cache for example.?

On Thu, Jun 11, 2015 at 12:41 PM, Steve Sheng <steve.sheng@icann.org> wrote:

Dear RSSAC Caucus,

This is a reminder for you to review the draft report on TTLs for the root zone. The review is due by close of business 15 June 2015.

In particular in your review, it would be great if you could comment on:

1) whether there are any factual errors with the document.
2) whether you agree with the study methodology and the conclusions that are drawn from these studies
3) whether you agree with the findings of the report
4) whether you agree with the recommendations in this report
5) whether you have any advice on which of the mitigation options articulated in section 6.4.3 should be preferred?

Also, are there any interest to have a briefing call on this report? Right now, the most likely time would be Monday 15 June.

Thanks,
Steve

From: Steve Sheng <steve.sheng@icann.org>
Date: Monday, June 8, 2015 at 1:37 PM
To: "rssac-caucus@icann.org" <rssac-caucus@icann.org>
Subject: [rssac-caucus] FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs

Dear RSSAC Caucus,

On behalf of the caucus work party on Root Zone TTLs, attached please find for your review the draft RSSAC Report on Root zone TTLs. The work party is chaired by Duane Wessels, work party members include Joe Abley, Jaap Akkerhuis, John Bond, Brian Dickson, Shumon Huque, Warren Kumari, Duane Wessels (work party leader) and Matthew Thomas (invited expert). Staff support are: Steve Sheng, Barbara Roseman and Kathy Schnitt.

Root zone TTLs have not changed since 1999. In this report, the RSSAC caucus studies the extent to which the current root zone TTLs are still appropriate for today’s internet environment. The report contains a number of findings and recommendations through four sets of empirical analyses. The work party chair invites you to give this report a careful review.

One thing the chair wish to highlight is that the work party discovered two potential problems related to the interaction between the SOA Expire value and the root zone’s signature validity period. It also identified several mitigation options, and conducted a preliminary analysis of these options. However, the work party has yet to reach a conclusion to recommend which measure to take. It would be good to hear some feedback from the Caucus. Short of more definitive feedback from the Caucus, the work party will recommend further consultation in this area.

The work party chair requests you provide your review by close of business (anywhere around the world) 15 June 2015, if possible. This will allow the work party time to discuss and finalize the document in time for RSSAC consideration in Buenos Aires.

All the best,
Steve

_______________________________________________
rssac-caucus mailing list
rssac-caucus@icann.org
https://mm.icann.org/mailman/listinfo/rssac-caucus

Daniel Migault

Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada

Phone: +1 514-452-2160