[rssac-caucus] REMINDER - FOR REVIEW: DRAFT RSSAC Report on Root zone TTLs
Warren Kumari
warren at kumari.net
Wed Jun 17 13:32:15 UTC 2015
Whooo. Something I don;t think we remembered to mention in the doc --
perhaps we should toss in a mention?
http://www.mail-archive.com/bind-users@lists.isc.org/msg21023.html
Basically upwards referrals triggering fetches (and cache exhaustion,
which we *might* have mentioned). Related to the topic, perhaps worth
mentioning just for completeness?
W
On Tue, Jun 16, 2015 at 11:06 AM, Steve Sheng <steve.sheng at icann.org> wrote:
> Thanks Shinta!
>
> Steve
>
> On 6/15/15, 11:06 PM, "Shinta Sato" <shinta at jprs.co.jp> wrote:
>
>>Hi Steve-san,
>>
>>Please check the below comments.
>>Sorry for my late response that I missed the CoB of 15 June in Japan,
>>but I believe it is still okay in other countries.
>>
>>----------------
>> 1) whether there are any factual errors with the document.
>>
>> I didn't see the factual errors, but came up with some questions
>> and editorial comments. These should be addressed.
>>
>> - The expressions in the terminology part varies.
>> - reference to the RFCs exists or not
>> - way to refer the RFCs
>> - link to the URL exists or not
>>
>> - Some abbreviation and words are used without enough descriptions.
>> ex) AA, TLD, Root Glue, TLD Glue,
>> NS RRset TTL (whether glue of root(.) itself or TLD
>>delegation?)
>>
>> - In the description of the SOA, nothing is mentioned for the
>> REFRESH and RETRY. These can be described in combination with
>> EXPIRE, as the parameters for the secondary name servers to
>> determine the zone transfer timing.
>>
>> - In the last paragraph of 6.1.1, the word RTT is used to
>> explain the Figure 2. I could not understand this expression
>> because the Figure 2 does not contain any information about
>> RTT. The figure might be wrong.
>>
>> 2) whether you agree with the study methodology and the conclusions
>> that are drawn from these studies
>>
>> I could not find specific problem statement throughout the
>> document. Thus, the motivation of this study is not clear enough.
>> It would be better if we can set up the problem with case examples
>> or specific patterns.
>>
>> 3) whether you agree with the findings of the report
>>
>> no objections.
>>
>> 4) whether you agree with the recommendations in this report
>>
>> no objections.
>>
>> If the issue is logically problematic, it should be fixed. But
>> the other issues which has not been seen as the current
>> operational problem do not need to be actively addressed. The
>> recommendations match this way.
>>
>> 5) whether you have any advice on which of the mitigation options
>> articulated in section 6.4.3 should be preferred?
>>
>> The parameters which is not causing the operational problem
>> directly should not be changed easily. If we shorten the Expire
>> period, there may be negative operational impact in the case of
>> communication trouble between root-zone distributor and
>> root-servers. The parameter of the DNSSEC validity period is the
>> place we can be changed without other impact.
>>----------------
>>
>>Just let me know if you have any questions in above comments.
>>
>>Best Regards,
>>
>>Shinta Sato <shinta at jprs.co.jp>
>>Japan Registry Services Co., Ltd.
>>
>>On Thu, 11 Jun 2015 16:41:37 +0000
>>Steve Sheng <steve.sheng at 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 at icann.org>
>>> Date: Monday, June 8, 2015 at 1:37 PM
>>> To: "rssac-caucus at icann.org" <rssac-caucus at 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 today1s 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 zone1s 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 at icann.org
> https://mm.icann.org/mailman/listinfo/rssac-caucus
>
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
More information about the rssac-caucus
mailing list