Skip to main content

IETF Last Call Review of draft-ietf-emailcore-as-26
review-ietf-emailcore-as-26-artart-lc-smyslov-2025-12-22-00

Request Review of draft-ietf-emailcore-as
Requested revision No specific revision (document currently at 28)
Type IETF Last Call Review
Team ART Area Review Team (artart)
Deadline 2026-01-06
Requested 2025-12-16
Authors Dr. John C. Klensin , Ken Murchison
I-D last updated 2026-04-27 (Latest revision 2026-04-08)
Completed reviews Dnsdir IETF Last Call review of -26 by Scott Rose (diff)
Genart IETF Last Call review of -26 by Vijay K. Gurbani (diff)
Artart IETF Last Call review of -26 by Valery Smyslov (diff)
Secdir IETF Last Call review of -26 by Shivan Kaul Sahib (diff)
Dnsdir IETF Last Call review of -28 by Nicolai Leymann
Opsdir IETF Last Call review of -28 by Jürgen Schönwälder
Secdir IETF Last Call review of -28 by Shivan Kaul Sahib
Assignment Reviewer Valery Smyslov
State Completed
Request IETF Last Call review on draft-ietf-emailcore-as by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/HGffB2N3pOKRL4orUhI-E_WBRoY
Reviewed revision 26 (document currently at 28)
Result Almost ready
Completed 2025-12-22
review-ietf-emailcore-as-26-artart-lc-smyslov-2025-12-22-00
I am the assigned ART directorate reviewer for this document. These comments
were written primarily for the benefit of the ART area directors.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

The document describes an applicability statement for electronic mail. It is
well written and easy to read.

I have one question to the authors (it can also be treated as an issue).
Sections 2.1, 2,2, 3.1, 3.4, 4.1, and 4.3 do not contain any RFC2119
recommendations for how to deal with the situations they describe. Is it
intentional? It seems to me that some RFC 2119 language should be used there
(e.g. instead of "discouraged", "should", etc.).

Nit (Section 2.2): I think that an 8-line sentence is a little bit too long.
Perhaps splitting it would improve readability (not that it is unparsable, but
still).