Re: [DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

2018-04-05 Thread Matthijs Mekking
Mark, On 04/04/2018 03:52 PM, Mark Andrews wrote: Note that implicit RRSIG deletion is idempotent, so it does not matter if two RRs in the MIXFR trigger it. Not if you are processing the additions on a RR by RR basis. You can add a new RRSIG before you add the covering RR. You need to perf

Re: [DNSOP] Request to DNSOP chairs for a WGLC on draft-ietf-dnsop-kskroll-sentinel-11.txt

2018-04-05 Thread Job Snijders
Dear kskroll sentinel authors, working group, On Thu, Apr 05, 2018 at 11:45:18AM +1000, Geoff Huston wrote: > With the submission of the -11 version of this draft the authors are > of the view that all WG comments have been discussed, and we think we > are now ready for a WG Last Call on this docu

Re: [DNSOP] Request to DNSOP chairs for a WGLC on draft-ietf-dnsop-kskroll-sentinel-11.txt

2018-04-05 Thread Paul Hoffman
On 5 Apr 2018, at 5:44, Job Snijders wrote: Dear kskroll sentinel authors, working group, On Thu, Apr 05, 2018 at 11:45:18AM +1000, Geoff Huston wrote: With the submission of the -11 version of this draft the authors are of the view that all WG comments have been discussed, and we think we are

[DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-05 Thread tjw ietf
After walking through the 168 emails on this draft in the inbox, I feel we're ready to take this to WGLC. (We are aware of the two points raised my Job and Paul) This starts a Working Group Last Call for: draft-ietf-dnsop-kskroll- sentinel Current versions of the draft is available here: https

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-05 Thread Job Snijders
Hi all, While the chair notes awareness of the point I raised, I’d like the be explicit to avoid any confusion. This document is *not* ready for publication. There is no implementation report available for review and consideration. Should the working group produce an implementation report and de

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

2018-04-05 Thread tjw ietf
Thanks Job for keeping *me* straight. Tim On Thu, Apr 5, 2018 at 1:15 PM, Job Snijders wrote: > Hi all, > > While the chair notes awareness of the point I raised, I’d like the be > explicit to avoid any confusion. > > This document is *not* ready for publication. There is no implementation > re

Re: [DNSOP] raising the bar: requiring implementations

2018-04-05 Thread 神明達哉
At Wed, 4 Apr 2018 11:22:33 +0200, Petr Špaček wrote: > >> This is actually quite a good example of another problem: > >> Client-subnet was documented for Informational purposes; it was > >> already in wide use in the public internet and had an EDNS opt code > >> codepoint allocated from the IANA

Re: [DNSOP] raising the bar: requiring implementations

2018-04-05 Thread tjw ietf
What is work: An "informational" document being used as standard is people taking a submitted (expired) draft as "standard"? Tim On Thu, Apr 5, 2018 at 1:39 PM, 神明達哉 wrote: > At Wed, 4 Apr 2018 11:22:33 +0200, > Petr Špaček wrote: > > > >> This is actually quite a good example of another p

Re: [DNSOP] raising the bar: requiring implementations

2018-04-05 Thread 神明達哉
At Thu, 5 Apr 2018 13:46:29 -0400, tjw ietf wrote: > What is work: An "informational" document being used as standard is people > taking a submitted (expired) draft as "standard"? I'm not sure how to interpret it (not even sure if it's a question to me)...but I guess what I think is the most imp

[DNSOP] re original_transport indicator

2018-04-05 Thread Patrick McManus
Hi All, We've had quite a thread re the -05 optional parameter to the dns-udpwireformat registration. The parameter is defined as having no meaning for DoH, but was included to accommodate a use case the dnsop wg is considering. Future proofing, if you like. Upon consideration (and a read of 683

Re: [DNSOP] [Doh] re original_transport indicator

2018-04-05 Thread Hewitt, Rory
Good idea - future-proofing is great in theory, but it sounds like there's a lot of non-consensus on the DNSOP side that we might end up adding something that is superseded anyway. Rory From: Patrick McManus [mailto:pmcma...@mozilla.com] Sent: Thursday, April 5, 2018 1:54 PM To: Martin Thom

Re: [DNSOP] raising the bar: requiring implementations

2018-04-05 Thread Andrew Sullivan
On Wed, Mar 28, 2018 at 05:24:33PM +0200, bert hubert wrote: > allow the one remaining closed source DNS implementation Really? I'm so pleased we have not only candidate censors of what is going to be published by the WG but also census-takers who have determined then number and types of DN

Re: [DNSOP] re original_transport indicator

2018-04-05 Thread Martin Thomson
+1 to this. And maybe there is an outcome that doesn't need this parameter. I probably misunderstood some of the expectations people have for the parameter. With the benefit of time and sleep, it's possible that I now understand the disconnect. My model of content-type - and by extension its pa

Re: [DNSOP] raising the bar: requiring implementations

2018-04-05 Thread Evan Hunt
On Thu, Apr 05, 2018 at 01:31:37PM -0700, 神明達哉 wrote: > At Thu, 5 Apr 2018 13:46:29 -0400, > tjw ietf wrote: > > > What is work: An "informational" document being used as standard is people > > taking a submitted (expired) draft as "standard"? > > I'm not sure how to interpret it (not even sure