On Fri, Mar 24, 2023 at 9:59 AM Dave Crocker <d...@dcrocker.net> wrote:
> On 3/24/2023 9:38 AM, Murray S. Kucherawy wrote: > > I think I concur with the suggestion that wa should drop discussion of > > ARC. This WG, or the DMARC WG, can develop an update to ARC based on > > the outcome here if the community chooses to do so, but I don't think > > it should be part of this WG's premise. > > sigh. The draft only makes a quick, careful reference to ARC's having a > similar vulnerability. Given it's underlying similarity to DKIM and > given that this is an introductory document rather than a specification, > I think it appropriate to give the reader a heads up. (FWIW, for early > versions of the draft I was also inclined to want it out. I think the > current, brief text is, however, apt.) > Fine with me, it's far from a showstopper overall. I just made the suggestion. > > Section 1.2: > > > > The opening sentence that emphasizes non-use of RFC 2119, amusingly, > > forces you to include a reference to RFC 2119. I suggest instead: > > "This document is not normative in any way." > > As I recall, there was some discussion about this. For one thing, the > IETF really likes seeing the reference. Including it ensures no hiccups > in the mechanics of handling the document. (And, yes, it is amusing.) > I've seen at least the current IESG encourage removal of the reference when it's not really needed. It's harmless to leave it in, I suppose, but I'd be unsurprised to get the question again during IESG Evaluation. > > Section 6 can simply say there are no security considerations for a > > problem statement document, though you anticipate some interesting > > ones in documents to follow. :-) > > Hmmm. On the other hand, have some discussion of security-related > issues in a section identified for that topic, might be useful for > highlighting dangers or concerns. > I've always thought of Security Considerations as a place to hold a discussion about what security issues are being introduced by the material in the document. I don't think any are or will be here, which was the point I was making. Those would come in any follow-on protocol or best practices work. Then again, I don't think anyone's going to complain if we do have an informative security discussion. So, as before, just a suggestion. -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
