Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-dnsoquic-10: (with COMMENT)
Hi Sara, On Tue, Mar 22, 2022 at 2:40 AM Sara Dickinson wrote: > > In Section 5.5: > > > > Clients SHOULD consider potential privacy issues associated with > > session resumption before deciding to use this mechanism. [...] > > > > I find "SHOULD consider" to be far too vague for this to be meaningful. > If > > I've thought about it, have I met my burden here? > > There are several things to evaluate here - we’ve updated this text to: > “Clients SHOULD consider > potential privacy issues associated with session resumption before > deciding to use > this mechanism and specifically evaluate the trade-offs presented in the > various sections of this document. The privacy issues are detailed…" > > Does that address your concern or can you suggest text? > I'd be fine with either the original or proposed text if you make it a lowercase "should". I guess for me this comes down to: Why is this a "SHOULD" and not a "should"? What specific normative obligation are you imposing with this sentence that affects interoperability of the protocol? If after considering potential privacy issues, it's really the case that there are specific protocol things I need to do, then I would enumerate those explicitly and make them SHOULDs. But a general "You SHOULD think about this" doesn't feel to me like correct use of BCP 14 keywords. -MSK ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Murray Kucherawy's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
On Thu, May 6, 2021 at 4:53 AM Sara Dickinson 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 dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Murray Kucherawy's Yes on draft-ietf-dprive-bcp-op-12: (with COMMENT)
On Fri, Jul 10, 2020 at 1:40 AM Sara Dickinson wrote: > > I suggest getting rid of use of BCP 14 entirely. There are only two > SHOULDs in > > the whole thing, and I don't think you need them. > > This point has been discussed a few times - the WG considered a few > alternatives and this was what eventually got consensus. We also added new > text in the -12 version (suggested by Ben Kudak) at the end of section 5 to > clarify the point that there are normative requirements here: “The rest of > this document does not use normative language but instead refers only to > the three differing classes of action which correspond to the three named > levels of compliance stated above. However, compliance (to the indicated > level) remains a normative requirement.” If you want to suggest a further > update to this text, please do. > Hi Sara, thanks for your consideration. As far as I can tell -- and I fully admit that's without the benefit of having been part of the WG's deliberations -- the two SHOULDs ought to be MUSTs, otherwise an operator could do neither of them and still be compliant with the BCP because "I have my reasons". And if you're going to make them MUSTs, then you can just say "implements" instead of "SHOULD implement" and "publishes" instead of "SHOULD publish", and then you don't need BCP 14 at all. The normative force of the BCP's text is not reduced merely by not using BCP 14. All that said, this is a comment to a YES ballot, so my advice is worth what you paid for it. :-) -MSK ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
