On Sun, Oct 27, 2024 at 9:11 PM Dave Crocker <dhc@xxxxxxxxxxxx> wrote:
Eric,
On 10/27/2024 9:01 PM, Eric Rescorla wrote:
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?
I think Donald did that in his review. I'm agreeing with him.
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.
As I said, I'd prefer the security considerations in this document to be complete but I could live with them being in a separate document provided there was a normative reference to said document. If you don't think that's a valid alternative, then I think the appropriate resolution is to properly update the security considerations in this document.
-Ekr
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
