On Sun, Oct 27, 2024 at 8:53 PM Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
On 10/27/2024 8:44 PM, Eric Rescorla wrote:
> Document: draft-ietf-emailcore-rfc5321bis-32.txt
>
> I find myself in agreement with Donald here as far as the Security
> Considerations go. Section 5 of RFC 3552 states in part:
RFC 5321 was written after RFC 3552, and it was found to be satisfactory
at the time.
Agreed, but I don't think that binds our decisions today. The question is whetherthis document has adequate security considerations and in my opinion itdoes not.
If the w/g says the Security Section is fine, isn't the burden to claim otherwise on the reviewer, rather than the reviewer issuing general requirements?
While the list you originally supplied might be fine, the fact that the previous version of the spec passed muster should define a presumption of sufficiency now. At the least at this stage it should raise concern if there imposition of what might be considerable work, to satisfy a form requirement, rather than any explicit specific substance concerns.
The current document is a revision that worked to avoid introducing new
technical substance.
And that's why I can live with a normative reference to the AS, provided thatthat it is sufficiently complete.
huh? An A/S is supposed to be about using one or a collection of
specification. Having a specification make a normative reference
back to an A/S essentially makes the two a single document and
confuses the separation of roles. For some reason the term
'deadly embrace' comes to mind.
Given the nature of an A/S, this can't be called a layer violation, but it is the same failure to keep separate roles properly.
d/
-- Dave Crocker Brandenburg InternetWorking bbiw.net mast:@dcrocker@mastodon.social
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
