On Thu, Mar 27, 2025 at 1:10 PM S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote:
It is highly unusual to be asked to read a long thread. As a mild
suggestion for the future, it might be better to provide a short
summary to make it easier for people interested in last-calls.
I don't know about "highly". We did it all the time when I was on the IESG. :-)
A summary would be a nice idea, but I found when I attempted to summarize it that my biases (or, at least, my interpretations) kept sneaking in. I felt it better to suggest people go to the raw material. It didn't occur to me to point an AI summarizing service at it; maybe next time.
There was some input from John Levine and Dave Crocker which puzzled me.
Reference [17] of draft-ietf-emailcore-rfc5321bis-42, which is a
normative reference, lists an Applicability Statement for IETF Core
Email Protocols (draft-ietf-emailcore-as-16). The Applicability
Statement has an informative reference to
draft-ietf-emailcore-rfc5321bis-41.
1. I would expect an applicability statement of a protocol to have a
normative reference to the protocol instead of informative reference
to the protocol. That would be the version of
draft-ietf-emailcore-rfc5321bis which is published as an IETF RFC.
The rationale for the above expectation is that a normative reference
is described as "essential to implementing or understanding the content
of the RFC" in the RFC Style Guide.
I think this is a minor point not germane to the LC (it's really about the AS, not the document under LC), but I agree.
2. If (1) is followed, it causes a circular dependency. I glanced through
the RFC Series and I came across several instances cautioning the reader
against circular dependencies.
Would it be okay to have two technical specification referencing each
other in such a manner (please see the two points)?
An AS isn't a technical specification, per RFC 2026. It refers to one, and describes how to achieve this or that using a given TS, but it is not itself one.
Would it be okay to have a technical specification about core
protocols which do not have a normative reference to those core protocols?
If both are TSes, I would argue that this is fine if there's some organizational reason to do them separately rather than as an omnibus document. In this case we have a venerable protocol with a lot of complexity and great care toward backward compatibility and preservation of detail, and the length of that is already such that drawing a line in the sand before presenting non-core material is an attractive idea. One of the attractive notions to me is that if we ever want to change the "how to use this on the modern Internet" advice, we only have to replace or update the AS, not an entire omnibus document which usually creates a hard-to-contain opportunity to tweak lots of things.
There is a reference to POP2 (RFC 937). That technical specification
was reclassified as Historic [1]. I see it as a case where it makes
sense to drop the reference. Anyone interested in POP2 will still
be able to the specification which draft-ietf-emailcore-rfc5321bis
intends to supersede.
I would agree.
With respect to the main question, I fall in the camp of not mentioning authentication solutions in the base document at all (and removing any that are there), and moving all such material to the AS. I'm ambivalent about whether DKIM ought to be normative there. I think STARTTLS has probably earned a "mandatory to implement" sort of mention in the AS which justifies the AS being a normative reference. I don't know that DKIM rises to that level. It may be that some large operators consider it mandatory to implement, but it doesn't provide protection against pervasive monitoring or anything of the sort, upon which the IETF has chosen to make much broader assertions. DKIM at best provides what I consider to be a weak authentication function. I would make it an informative reference.
-MSK
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
