I had advocated early and frequent rollovers for precisely the reason: keep doing it until it’s easy, so we’re in strong agreement.
Yes, this one actually went smoothly but there was some tension. Aside from any specific improvement, reducing the tension and sense of drama is mainly what I had in mind. Thanks, Steve On Mon, Oct 29, 2018 at 8:23 PM Joe Abley <jab...@hopcount.ca> wrote: > Hi Steve, > > There will always be the potential for tension between the desire to > perform measurement and the need for privacy. In this case it seems to me > that a well-intentioned and competent authority, supported by a > well-intentioned and occasionally-coherent community has a plausible and > sensible desire to understand the configuration of resolvers. I imagine > others might see things differently, however. I suspect that having a clean > signal that can be relied upon is going to at least change the extent to > which client infrastructure is private. > > Your last paragraph caught my eye, though. It could be argued that the > rollover that just completed was straightforward, at least from a technical > perspective. The delays, uncertainty, concern and unfulfilled doomsaying > were the things that made it difficult. (It's easy to load that last > sentence so that the concern looks ridiculous given the outcome; I am fully > aware that the hyperbole would be the thing that looked ridiculous if > things had turned out differently.) > > To what extent does a regular and frequent cadence of key rollovers > obviate the need for concern? It seems to me that at some point down the > road if a key roll breaks someone's network, it's going to be much easier > to point the finger at the network operator than at whomever is responsible > for rolling the key. Perhaps the way to eliminate the things that made the > first rollover hard is just to keep doing it until it's officially easy. > > > Joe > > On 29 Oct 2018, at 18:46, Steve Crocker <st...@shinkuro.com> wrote: > > I won't be in Bangkok, so I won't be able to participate. In my view, > there were two specific problems that dominated the rollover problem. The > first was the inability to determine the configuration of querying > resolver. The second was the in ability to notify resolver operators if it > was evident their software was misconfigured. > > Although these two problems became evident and important during the > rollover, they also apply more generally, so if the IETF is going to work > on improvements, it would be helpful if the improvements would be useful in > the event of other configuration or operational issues. Ideally, every > resolver that issues a query would provide configuration information, > perhaps in a controlled fashion, and there should also be a way to notify > the resolver operator of operational problems. > > We will need to do more rollovers in the future, driven at least in part > by the need to change algorithms. I would hope we can work toward making > these relatively straightforward. > > Thanks, > > Steve > > > On Mon, Oct 29, 2018 at 12:36 PM Dave Lawrence <t...@dd.org> wrote: > >> Dave Lawrence writes: >> > Count me as another, for that very reason. When I first saw Paul's >> > message I thought, "oh that's a shame" but figured it to be fairly >> > set. If there's flexibility for making the meeting happen earlier in >> > the week, I'd be interested. >> >> Following up to my own message, since this was further down in my box >> on another list... >> >> ------- start of forwarded message (RFC 934 encapsulation) ------- >> From: Paul Hoffman <paul.hoff...@icann.org> >> Subject: Re: [ksk-rollover] Informal meeting at IETF 103 >> To: "ksk-rollo...@icann.org" <ksk-rollo...@icann.org> >> >> Based on some requests from folks who are leaving the IETF meeting >> early, I have also reserved a meeting room for 1600-1700 Wednesday >> afternoon (local time), Pagoda Room on the 4th floor. >> >> And just to emphasize: the purpose of this week's informal gatherings is >> to let folks in the IETF community chat about their ideas in front of >> other IETFers. This is similar to the KSK-related mic lines at the >> DNS-OARC and RIPE meetings a few weeks ago. These IETF side-meetings >> really are just slightly-better-organized hallway discussions. Given the >> wide range of proposals we have already heard, it is good to get a bit >> of face-to-face sharing going early. >> >> We won't start formal planning about the KSK futures until after the >> rollover process is complete*. When we do, we'll do it in discussion >> environments that are much more inclusive than these informal IETF >> side-meetings or the mic lines at other technical meetings. >> >> [...] >> ------- end ------- >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
