On Thu, May 6, 2021 at 4:53 AM Sara Dickinson <[email protected]> wrote:
> > Section 7: > > > > * "Implementations SHOULD use [RFC7828] [...] to manage persistent > > connections." -- since this is a SHOULD, can you suggest why an > implementer > > might opt not to do this? Section 7.3.1 does a great job of handling the > > SHOULD it presents, for example. > > Implementations typically include an option to use fixed timeouts on > either side of a connection for simplicity which can work just fine for > e.g., low transfer rates - I could add text to that effect? > Yes, something that rounds out this SHOULD story would be great. > Sections 7.3.2 and 7.3.3: > > > > * Same issue as above with the SHOULDs here. > > Short answer, backwards compatibility. > > For 7.3.2 there was a discussion in the working group about the > significant code complexity involved for several implementations to meet > all 3 requirements (particularly the second two points). Since the > performance improvements gained from these features is desirable, but not a > critical for XFR, the discussion resulted in the SHOULD. Again, could add > text on that if needed? > Adding something like that would be helpful, yes. For 7.3.3, there is no previous specification for this behaviour and > nameservers may behave differently today, hence the SHOULD here. > Same. > Section 7.4: > > > > * "Therefore, it is RECOMMENDED that [...] there SHOULD be no more than > [...]." > > -- I don't know how to reconcile this RECOMMENDED-SHOULD combination in > the > > same sentence. I suggest that the first clause can be dropped with no > loss of > > meaning. > > Double checking this I remembered that for consistency the text is > actually lifted and tweaked from RFC7766 which it is updating which said: > “It is RECOMMENDED that for any given > client/server interaction there SHOULD be no more than one connection > for regular queries, one for zone transfers, and one for each > protocol that is being used on top of TCP (for example, if the > resolver was using TLS). " > > So we could update it if you feel very strongly? > Alas, no. If you're copying this from something that already has consensus, it's probably best to leave it. Thanks for checking. -MSK
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
