Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

神明達哉 wrote: At Wed, 15 Nov 2017 05:41:04 +, P Vix wrote: 1) when the request explicitly signals it is ok; 2) when the request groks EDNS but might or might not understand a staleness option; or 3) in all cases. My current understanding is that you and Paul are of

[DNSOP] draft-ietf-dnsop-isp-ip6rdns

I updated this draft months ago, based on feedback from the previous WGLC, and it expired without comment. I’ve refreshed it, and would like to ask again for reviews (especially if anything has changed in the past year) and another WGLC.

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

At Wed, 15 Nov 2017 05:41:04 +, P Vix wrote: > >1) when the request explicitly signals it is ok; > >2) when the request groks EDNS but might or might not understand > > a staleness option; or > >3) in all cases. > > > >My current understanding is that you and Paul are of

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

On 16 November 2017 at 00:23, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > I support

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

> the draft uses Vnew Vold Vleg and nonV without description. > that makes it hard for me as I still do not fully understand the idea ... Well it is defined/described in section 3 but I agree that a high level explanation in the terminology section would not hurt. Manu

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

tjw ietf: The draft is available here: https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ the draft uses Vnew Vold Vleg and nonV without description. that makes it hard for me as I still do not fully understand the idea ... Andreas

Re: [DNSOP] 5011-security-considerations and the safetyMargin

Wes, My preference is to include safetyMargin and have text to explain it exists because of network delays etcetera, and also reference to RFC 5011's retryTime. So that's some mix of 1B 1C or 2B I guess :) Best regards, Matthijs On 15-11-17 02:49, Wes Hardaker wrote: The discussion has

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

I support adoption, will review. Petr Špaček @ CZ.NIC On 16.11.2017 09:23, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

On Thu, 16 Nov 2017, tjw ietf wrote: The author has rolled out a new version addressing comments from the meeting on Monday, and we feel it’s ready to move this along. This starts a Call for Adoption for draft-huston-kskroll-sentinel The draft is available here:

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

I support adoption and am willing to contribute and review. > On Nov 16, 2017, at 16:23, tjw ietf wrote: > > All > > The author has rolled out a new version addressing comments from the meeting > on Monday, and we feel it’s ready to move this along. > > This starts a Call

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

I support adoption of this work. Its a sensible, simple proposal which has immediate benefit, and can be used by anyone to test the ability of their nominated resolver to recognise specific keys, and their trust state. I believe as a community, at large, we need code deployed into the resolvers

[DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

All The author has rolled out a new version addressing comments from the meeting on Monday, and we feel it’s ready to move this along. This starts a Call for Adoption for draft-huston-kskroll-sentinel The draft is available here: https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/