On Apr 10, 2023, at 10:45 AM, Wes Hardaker <hardaker@isi.edu> wrote:
Sorry to miss this by a day or two (I'm not sure which side of the dateline I'm on right now...), but I believe we need to pause this document until we know more about how BCP40 might change. I had good conversations with the authors, Marc Blanchet and Wes Hardaker, and I am not at all sure that the wording we use in the current draft of RSSAC001v2 will make sense in a variety of scenarios for BCP40bis.
The last discussion about the bis document had multiple people leaning toward "7720 shouldn't be updated", but with an additional thought of producing a new document instead that adds recommendations (but not requirements) to the BCP. The diverse opinions on this subject really need to come up with a middle ground or solidify on one of the extremes.
But I do wonder how separate we can make the RSSAC document from the IETF document. IE, what would it take to allow RSSAC001v2 to be published regardless of the future BCP status or contents. Part of the point was to separate them so that the contents of each wouldn't depend on the contents of the other, aside from a notion of "go read this too". That's clearly an idealistic desire, however, but I think we should strive for it so that they can be updated independently in the future as much as possible. If it's possible.
My apologies for the late reply here, but I do think we need to keep this discussion going. The current draft of RSSAC001v2 says: ===== [E.3.1-B] Each RSO is expected to deliver the service in conformance to IETF standards and requirements as described in BCP 40. BCP 40 describes the protocol and deployment requirements for the DNS root name service. An RSO is expected to provide the service in compliance with the requirements outlined in BCP 40. ===== The expectation in the title is incorrect. BCP 40 (RFC 7720) has requirements for the root service as a whole, not each server in the root service. The first sentence in the description is correct, but the second is not for the same reason. The requirements for the root service can be met even if some of the server operators do not meet every requirement. One obvious example is the IPv6 requirement. If Q-root and R-root don't support IPv6, that doesn't affect whether the root service as a whole supports IPv6. It is just fine for some of the nameservers to only have glue records for A, not for AAAA, as long as some of the glue has AAAA records. E.3.1-B currently doesn't make sense as it is currently stated because it refers to a document that doesn't put any requirements on the nameservers for the root. There are a few ways to fix this. 1. Remove it, meaning that there is no technical expectation on an RSO. 2. Change it to indicate that each RSO is expected to meet each requirement in BCP 40, while admitting that BCP 40 is about the RSS as a whole. 3. Remove the linkage to BCP 40, and list the actual requirements that RSSAC wants (which is probably the list from BCP 40, plus maybe more.) My personal feeling is that doing #3 is probably best for readers of RSSAC001, but any of them would work. Of course, there may be other options as well. --Paul Hoffman