On Mon, Apr 27, 2020 at 8:09 AM Joe Abley <jab...@hopcount.ca> wrote:
> On 25 Apr 2020, at 00:30, Shumon Huque <shu...@gmail.com> wrote: > > On Fri, Apr 24, 2020 at 6:21 PM Gavin McCullagh <gmccull...@gmail.com> > wrote > > That's one way to approach it. What I was thinking was, if the >> registries want to dictate the TTL, that seems understandable. But in so >> doing, they could have a process where they dictate a lowered TTL (of their >> choice) for a period after each change, then raise it back up to normal in >> order to reduce the impact of mistakes/problems. A "bake period" >> essentially. The timers would be argued about of course, like all magic >> numbers, but something conservative like an hour would seem like a major >> improvement on today. Hypothetically, would you consider that would >> improve your use case? >> > > Based on my experience, I doubt that registries would do this. I could be > wrong though, and perhaps we should ask and get them to respond to your > suggestion. But to answer your last question, the draft that has been > proposed is not about improving my own personal use case(s). > > As a contracted registry operator, we will do whatever the contract tells > us to do. > > However, it might be that centralising the requirements for this kind of > new mechanism in the form of legal contracts with ICANN, back-end registry > providers, etc might not be the most efficient way of deploying anything. > There are also many TLDs that are not contracted parties and who (properly, > sensibly) make their own decisions. If part of the goal is simplicity > through consistency, this seems like a poor approach. > Thank you Joe. In case it wasn't clear to others, my earlier expression of doubt was based on what I felt registries would be willing to do, if not contractually obliged to. I wasn't advocating Gavin's idea, but was interested in the view from registries nonetheless. More generally, putting the TTL for the NS set effectively in the hands of > the child zone operator provides maximum flexibility for appropriate values > to be chosen. Concentrating a TTL policy in the parent for all child zones, > regardless of downstream operational circumstances or personal preference, > seems a lot less flexible. > > With a child-centric approach, the NS RRSet TTL in the parent zone relates > to the parent infrastructure and is useful until the child can be reached, > at which point it can be replaced a value that makes sense for the child > infrastructure. This seems intuitive, simple and sensible. > Yes, I agree with this. (I also agree with Paul's qualification that we might be wise to avoid the use of the child/parent centric terms since the proposal on the table is about judicious use of information from both sides). Shumon Huque
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
