On Jan 29, 2021, at 9:31 AM, Michael StJohns <[email protected]> wrote: > I can't support this as Standards track even though it purports to update > standards as it doesn't actually specify an implementable protocol. > Basically, this is dependent upon humans doing the right thing, rather than > specifying behavior of the protocol.
I don't understand the context of this. The draft specifies that the protocol is changing, and now authoritative servers change the way they act from $x to $y. Where is the "humans" part? > For each of these, I'd recommend specifying what a client does in each of the > cases, rather than weasel wording the SHOULD with respect to the zone > contents to turn this into an implementable protocol. Here, I agree that the draft is unclear. It should say explicitly "resolvers keep doing $z, there is no change here". Also, for the text about authoritative servers, I agree that changing the SHOULDs from the current standards to MUSTs. I note that you didn't appear to accuse the authors of 4034, 4035, and 5155 of "weasle wording" when those documents were standardized. Doing so now seems out of line. > E.g. for each of these clauses add something similar to "The client > SHOULD/MUST reduce the effective TTL for the received NSEC RR to the lesser > of the TTL of the current SOA record, the TTL of the SOA, and the TTL of the > NSEC RR record and MUST discard the NSEC RR when that effective TTL expires." Again, this is not about the clients, as the document says (but not clearly enough). > So - not ready for last call. Sure it is. These are normal last call comments. In a similar vein, I think that the section on "No updates to RFC8198" should indeed update RFC 8198. The resolver might have the SOA in its cache, and thus could do the right thing even if the authoritative server has not been updated. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
