At 01:00 PM 30-03-2025, Murray S. Kucherawy wrote:
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.
I understand that it can be difficult to as there is room for the
usual miscommunications. An AI summarizer might work. Anyway, let
me get back to the topic.
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.
I agree that it could be ruled as unrelated to the last-call. I'll
comment below.
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.
I agree that an AS and a TS are conceptually different. The usual
rules apply, e.g. downward reference.
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.
draft-ietf-emailcore-rfc5321bis-42 has 124 pages, excluding the
documents which are referenced. That is a lot of reading. The TS
stood the passage of time and that's as good as it gets. Going over
all that again would be a very expensive effort.
I agree that it is better to have the material that does not preserve
backward compatibility in an AS.
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.
I'll use the word "standard" loosely. There are two standards. One
of them is not secure. The other one has some "mandatory to
implement" requirements for security purposes, e.g. to address user
concerns about security. The operator gets to choose which one to deploy.
I would move the following sentence into the Introduction Section:
"SMTP is not a secure protocol as that term is understood in the
contemporary Internet." I would then add the text from Section 1.3:
"Particularly important extensions and supplemental protocols,
including ones intended to address those security issues" and a
reference to the Applicability Statement. The editor could then get
away with an informative reference to the Applicability Statement.
As for the DKIM reference, the sentence about it was likely added
around 2007. The discussion in those days was about
"Return-Path". There was another discussion about that in 2014. I
am at a loss as to what text to suggest as the assertion is generic
enough to be quite weak.
Regards,
S. Moonesamy
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
