On 10/28/15 7:37 AM, yaojk wrote:
Hello
http://tools.ietf.org/wg/dnsop/agenda?item=agenda-94-dnsop.html
From the agenda above, I see that it doesn't include my draft
discussion. Could you kindly assignee 5 minutes to introduce the draft-
yao-dnsop-root-cache?
Thanks
Jiankang Yao
Hi
> 在 2015年10月28日,19:45,Tim Wicinski 写道:
>
>
>
>
>> On 10/28/15 7:37 AM, yaojk wrote:
>> Hello
>>
>> http://tools.ietf.org/wg/dnsop/agenda?item=agenda-94-dnsop.html
>>
>> From the agenda above, I see that it doesn't include my draft
>> discussion. Could you kindly
Petr,
I'm not sure how this was overlooked but we'll sort it out and get you a
response before the DNSOP f2f in Yokohama next week.
Thank you for being willing to work on resolving it, and our apologies for not
getting it in hand sooner.
best,
Suzanne
(for the chairs)
On Oct 23, 2015, at
Hello, AD here.
On 10/28/15 5:24 AM, yaojk wrote:
>
>
>
>
>> 在 2015年10月28日,19:45,Tim Wicinski 写道:
>>
>>
>>
>>
>>> On 10/28/15 7:37 AM, yaojk wrote:
>>> Hello
>>>
>>> http://tools.ietf.org/wg/dnsop/agenda?item=agenda-94-dnsop.html
>>>
>>> From the agenda above, I see that
Thanks, Joel.
As Joel points out for those who may not know-- the decision not to add this
draft to the agenda for the f2f meeting next week is within the discretion of
the WG chairs. However, in the interests of transparency, we have no problem
explaining the decision.
THe draft
On 10/28/15 4:24 AM, yaojk wrote:
It might be your power as chairman. But I think that your arguments
to block the draft discussion is not reasonable.
If I may take some liberty here ... discussion of the draft is
not blocked. Indeed, the primary place for working group discussions
to take
On Tue, Sep 29, 2015 at 5:20 AM, Shane Kerr
wrote:
> Jiankang Yao,
>
> I think a simpler approach that works in general is the "HAMMER"
> approach proposed by Warren Kumari, Roy Arends, and Suzanne Woolf a
> couple of years ago:
>
>
Bob Harold wrote:
> Reading these various ideas brings up a question in my mind. If a server
> queries for the SOA of a zone and the serial number has not changed, can it
> then assume that all of the entries in its cache for that zone should still
> be valid now, and for the their original TTL