--On Monday, April 8, 2024 06:40 +0200 Carsten Bormann <cabo@xxxxxxx> wrote: > On 8. Apr 2024, at 06:06, Bron Gondwana > <brong=40fastmailteam.com@xxxxxxxxxxxxxx> wrote: >> >> I suggest saying something like this in the security >> considerations: >> >> […] SHOULD […] > > The security considerations section is not the place to make > normative statements about the protocol. What *is* the security > consideration that would lead to such a set of statement? Carsten, I thought about that too but decided it was a separate issue that the authors and WG could work out with each other and the community. I share your preference for avoiding normative statements there, but it is a principle that has been violated enough times in the past that it is hard to claim that it is a hard rule. A tweak to the "experience has shown" text I suggested to Bron could clearly suggest a security consideration. Or one could pull the text Bron suggested out (with or without my addition) and put it somewhere else, perhaps in the little-used "Internationalization Considerations" section. As he suggested, I think we should leave it to the authors to make a more specific proposal rather than trying micro-edit the document on this list. > (I also think that this would be a rather heavy late change of the > protocol. Has the "Freeform Class as defined in PRECIS" been > examined to actually be useful for this application? [Quick, does > it say all the right things about bidirectional strings for contact > information?] Why is the server only to be restricted about setting > "names" while the client is restricted about displaying any > strings?) I think Bron covered the more substantive part of this but it seems to me that, if our model is that AD review after publication is requested followed by IETF Last Call are actually the first points at which we expect the IESG and the broader community to carefully review the document, this is no such thing as a too-heavy late change if those reviews spot a non-trivial deficiency or other problem. As I have said in other contexts, if the only substantive changes that can be made after IETF LC starts are to prevent earthshaking catastrophes, then we should stop claiming IETF Stream documents represent IETF consensus and start being more clear that they represent the consensus of a (possibly quite homogeneous) WG that the IETF community has had a chance to review and check. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
