Re: [DNSOP] WGLC draft-ietf-dnsop-session-signal

2018-02-13 Thread Bernie Volz (volz)
Sorry, I forgot one additional comment. While there seems not be a solid definition of what the “Updates” means in the RFC header, it always seems to me that “Updates” means you are changing something in those documents, rather than just extending them with new capabilities within the original

[DNSOP] WGLC draft-ietf-dnsop-session-signal

2018-02-13 Thread Bernie Volz (volz)
Hi: I have reviewed the document. In general, it is well written and ready to be advanced, though there are some nits that the authors should review and consider: Section 1: Not sure why Stateful is capitalized in the following line: transport protocol. Each Stateful operation is communicated

Re: [DNSOP] the ??-- thing (was Re: I-D Action: draft-huston-kskroll-sentinel-04.txt)

2018-02-13 Thread Matthew Pounsett
On 1 February 2018 at 16:20, Andrew Sullivan wrote: > I am not convince that "it should not" is true, and having thought > about this a little more it seems to me that an IANA registry should > have been created in the first place for this sort of miserable > in-label hack. If it had been, we co

Re: [DNSOP] Updated KSK Sentinel document

2018-02-13 Thread Warren Kumari
On Tue, Feb 13, 2018 at 1:49 PM, Wessels, Duane wrote: > >> On Feb 13, 2018, at 9:10 AM, Bob Harold wrote: >> >> If an entry could be put in the root zone, that is signed only with the new >> key, then could users query that and always get a yes/no answer to whether >> they will be affected? >

Re: [DNSOP] Updated KSK Sentinel document

2018-02-13 Thread Wessels, Duane
> On Feb 13, 2018, at 9:10 AM, Bob Harold wrote: > > If an entry could be put in the root zone, that is signed only with the new > key, then could users query that and always get a yes/no answer to whether > they will be affected? This doesn't work because when the new key is published in t

Re: [DNSOP] Updated KSK Sentinel document

2018-02-13 Thread Joe Abley
On 13 Feb 2018, at 12:10, Bob Harold wrote: > Thanks, the explanation helped. I finally realized that it only works if all > (or most) validating resolvers are updated to support this new feature, > otherwise we have a bunch of responses that are uncertain. Based on numbers of queries arrivin

Re: [DNSOP] Updated KSK Sentinel document

2018-02-13 Thread Vladimír Čunát
On 02/13/2018 06:10 PM, Bob Harold wrote: > [...] If an entry could be put in the root zone, that is signed only > with the new key, then could users query that and always get a yes/no > answer to whether they will be affected?  I don't think that's possible.  This is about the _single_ root DNSKE

Re: [DNSOP] Updated KSK Sentinel document

2018-02-13 Thread Bob Harold
On Mon, Feb 12, 2018 at 3:28 PM, Warren Kumari wrote: > > > Hi all, > > Sorry it has taken so long to get a new version of this document > posted - you deserve better. > > Anyway, we've finally posted an updated version - > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ > >