(No hats, and no strong feelings-- a minor point.) On Jul 8, 2015, at 11:11 PM, Evan Hunt <e...@isc.org> wrote:
> On Wed, Jul 08, 2015 at 09:50:09PM -0400, Warren Kumari wrote: >> Less flippantly, it is in this email: >> https://www.ietf.org/mail-archive/web/dnsop/current/msg13004.html I >> don't think that we have a really good motivation for a week, other >> than that is feels sort of like a good, human scale timeframe to >> recheck on things. We really want there to be a limit on the lifetime, >> a week felt right... > > Yep, that's pretty much it, right there. A day isn't enough (we had > feedback from customers to this effect) but anything longer than a week > strikes me as much too likely to fall off operators' radar. Though the > limit is arbitrary, I do believe that we need to assert *some* limit, > on this approximate time scale. OK, so….vendor feedback from customers sounds like a motivation that's perfectly appropriate to document. "There's limited experience with what this value should be, but at least one large vendor has documented customer feedback suggesting that a week is reasonable based on expectations of how long failures take to fix or to be forgotten. Operational experience may further refine these expectations." Agreed that there MUST be an expiration set (Sec. 2) but MUST (or even MUST NOT) always seems weird to me on a specific value, especially given that there's a SHOULD in Sec. 2 about letting the operator set the duration. How about: "NTAs MUST expire automatically when their configured lifetime ends. The lifetime SHOULD NOT exceed a week." This allows for enforcement in code if Evan wants, without requiring it. :-) Suzanne _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
