Paul Hoffman writes: > I'm not sure a standards track document that updates RFC 1034/1035 > should be recommending a minimum TTL.
As previously noted, we're making no such recommendation and that will be clarified. The first definition of "resolution recheck timer" in section 5 does already say that it regards failed lookups, but it seems that adding that distinction later is also warranted. > The document is actively confusing about recommendations. Before we go pushing around whole sections of text, could anyone please comment on whether they find it "actively confusing about recommendations"? Yes, they appear in a couple of different sections, for different reasons -- as described in the text the example method presented is just one possible way of doing things, with the core idea and the standards-relevant changes being distinct. The recommendations, however, are not in conflict with each other and I'm really not clear myself on where the criticism that they are confusing comes from. The mention of the explicit word "recommended" in section 6/6.1 is just reiterating the value described in section 5, and in the broader sense of recommendations section 6.1 is meant as how the recommendations were made. (Personally I'd renumber 6.1 -> 7, 7 -> 8, etc, but that's a minor separate issue.) Putting that discussion in a separate discussion doesn't bog down the basic description of the sample implementation. I don't object to reorganization in principle, if it makes notable gains, but I can't really fix what I don't understand the problem is. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
