OK, I agree that the document is not a step backward. It is not worse than what goes on now.
But shouldn't the document address the main technical problem directly, rather than obliquely? That would be the "bootstrapping" issue. For example, HSTS preload lists and just hardcoding 1.1.1.1 or similar address bootstrapping problems where it's not clear whether to use an encrypted protocol.
thanks,
Rob
On Fri, Jul 8, 2022 at 6:22 AM Ben Schwartz <bemasc@xxxxxxxxxx> wrote:
None of the issues I've identified here would lead to compatibility-breaking changes. Thus, in my view, the draft's technical content is essentially complete and acceptable, and the remaining changes are in the presentation, explanation, and perhaps some corner-case behaviors.On Thu, Jul 7, 2022 at 5:50 PM Rob Sayre <sayrer@xxxxxxxxx> wrote:On Thu, Jul 7, 2022 at 12:36 PM Benjamin Schwartz via Datatracker <noreply@xxxxxxxx> wrote:Reviewer: Benjamin Schwartz
Review result: Has Issues
I think there are some interesting open questions about the structure of this
document, and some details about how recommendations are described, but the
technical components are sound.Are the technical components sound? That's not clear to me, but I'd like to know more about your rationale.thanks,Rob
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
