On 8/1/2023 8:28 AM, Laura Atkins wrote:
Based on discussions, there seems to be favor to documenting what has
been tried and not worked.
Question for the working group: Should the discussion of what hasn’t
worked be in the problem statement as an Appendix? Or should it be in
a separate document as working group output?
Is the intent to publish the problems statement as an RFC? It isn't
immediately clear to me that it's worth the effort to do that, since one
would expect any 'solution' specification RFC to contain a basic problem
statement.
If this were a highly complex problem that required extensive
explanation, I could imagine wanting a separate document to be
published. Or if this were a research topic, expecting to need a long
time to produce a useful engineering response; then a published problem
RFC would mark the topic for wider awareness.
I think the current case is neither. The problem statement document is
useful as working text, for immediate use.
So, to answer you question: if the problem statement is NOT going to be
published, it doesn't matter whether case analysis details are in it or
in a separate draft.
Along the same lines, do members of the working group feel we should
include some of the solution space in the problem statement? Or should
the discussion be reworked?
Perhaps instead of "possible solution space" maybe "scenarios and how
they affect dkim replay" ? We welcome any suggestions of wording changes.
I think casting it in those terms will likely be more useful and less
likely to conjur philosophical debates.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
