Applicability Statement for IETF Core Email Protocols
draft-ietf-emailcore-as-30

[Ballot comment]
Thanks for addressing my discuss.  I'm happy we could find a 'middle ground'.

I'm leaving the below comments for historical reasons....

Thanks to Shivan Sahib for their multiple secdir reviews.

Section 6.1.2:  s/man-in-the-middle/person-in-the-middle.

Section 6.1.3:  Is this specification encouraging support for these protocols?  If so, it is hard to discern from the current text.  A simple change to the last sentence would make it more obvious.  Perhaps '...in this section is increasing, and encouraged, but is not yet...'.  Of course, I assume that reducing the opportunity of a 'person-in-the-middle' attack is a good thing.

References:  I suggest leaving a note for the RFC Editor to replace RFC8446 with RFC9846 (draft-ietf-tls-8446bis, currently in Auth48) should it be published prior to this specification. 

References:  While RFC9325 is listed, it might be more prudent to list BCP195, which loops in deprecations and will mandate TLS1.3 when draft-ietf-uta-require-tls13 (in Auth48) is published.

[Ballot comment]
Thanks to the authors and the WG for their work on this document. Also thanks for taking care of the reclassification of references as normative from my original ballot.

I would also like to request the authors to cross-check if some the following (and there may be others) should use their BCP14 keyword equivalents.

"This is particularly important for software that validates user-input fields, where case changes are tempting, but must be avoided."

"This is actually just a special case of a principle, discussed in Section 2.3.11 of [I-D.ietf-emailcore-rfc5321bis] and elsewhere, that nothing other than the final delivery system should attempt to interpret or alter the local-part of an address. In particular, they MUST NOT:" .... please consider if the first sentence is framed as a SHOULD NOT for other that the final delivery system.

"As already specified in Section 4 of RFC 4954, cleartext credentials MUST NOT be sent without TLS, and deployments should require use of an effective confidentiality mechanism, with SMTP AUTH such as TLS." ... perhaps SHOULD or RECOMMENDED instead of the should?

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-emailcore-as-29
CC @evyncke

Thank you for the work put into this document, it is probably long due...

Please find below some blocking DISCUSS (but easy to fix), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Murray Kucherawy for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Dirk Von Hugo, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-emailcore-as-29-intdir-telechat-von-hugo-2026-06-28/ (mainly minor nits)

Other thanks to Dave Lawrence, the DNS directorate reviewer:
https://datatracker.ietf.org/doc/review-ietf-emailcore-as-29-dnsdir-telechat-tale-2026-06-24/


I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 2.4

Why not a "MUST" in `All of those SHOULD be supported` as this sounds like a good action. See also: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

### Section 3.3

Why not a "MUST" in `When performing such functions, the MUA SHOULD` as this sounds like a good action. See also: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

[Ballot comment]

## COMMENTS (non-blocking)

### Use of "we"

Who is the "we" in sections 4.1 and 6.1 ? The authors ? The WG ? The IETF community ? Please avoid ambiguities.

### No Happy Eyeball discussion

I find it very sad that I don't see any discussion about RFC 8305 (Happy Eyeball) that could have been used to give a slight preference to IPv6 over IPv4 when resolving/connecting to a MX.

### Section 2.1

s/record/ressource record/ (to be pedantic)

### Section 6.5

As the issue has been raised to a DISCUSS level by other ADs, I will only support these DISCUSS about `In order to maximize interoperation and avoid refusal of legitimate messages, SMTP-receivers MUST NOT require SMTP-senders to use over-the-wire confidentiality mechanisms.` A "SHOULD NOT" is probably better (and the "in order..." is the required IESG BCP14 guidance).

[Ballot comment]
I strongly support the existing DISCUSS ballots, especially with regards to requiring support for unprotected communication, but that point has already been well-made.

I presume the reference re-classification will be trivial editorial work that requires no further commentary.

I have no other concerns.

[Ballot discuss]
* Very many of the references appear that they should be normative and not informative.  And possibly with a downref needed for RFC6973 if it's normative.

* I'm not sure why this is standards track.  It really seems like a BCP.  Many of the recommendations are based on current deployment and adoption of standards, which will evolve in time.  That seems best suited to "Best *Current* Practice".  Why is that not the case?  In defense of the 'MUST NOT' for confidentiality, Barry Leiba said:

> The issue has to be put into the perspective of what *this document*
> is meant to do.  Again: this document is an Applicability Statement
> that's telling implementers and deployers what they need to do in
> order to interoperate on the Internet *today*.

emphasis from Barry Leiba.  There are more references to current deployment.

[Ballot comment]
I do want to express my thanks to the editors for a well written draft; and after reading all the last call comments, I believe I understand the position of the WG and the editors and that this is a consensus draft.

Thanks to Shivan for the SECDIR review and Murray K. for the shepherding doc.

* I support Deb's discuss.  I believe that the 'MUST NOT' in 6.5 is too strong and would be better suited to a statement such as: "Implementations MUST continue to include an option to receive email without requiring confidentiality.  Local deployments MAY choose to require confidentiality by requiring STARTTLS before fully accepting an email under the consideration that such a choice would be actively blocking valid non-malicious mail traffic."


* I also agree with Roman's discuss; the applicability of this appears to be open-Internet operation?  In the last call traffic there was some comments about local operation (within a domain) vs external acceptance.  This nuance, when appropriate, doesn't seem to be well reflected in this document.

[Ballot comment]
# IESG review of draft-ietf-emailcore-as-29

CC @MikeBishop

## Comments

### Intended Status

This reads very much like a BCP. What new protocol elements does it
define that make it Standards Track, rather than "how best to use the existing
SMTP specs" guidance?

### Section 6.5, paragraph 7

It seems to me that "maximize interoperation" and "avoid refusal of
legitimate messages" are the explanations that would generally accompany a
SHOULD NOT. There are bad results if you don't follow this guidance, so beware
if you make that choice. Therefore, I question making this a MUST NOT.

That is to say, I support Deb's DISCUSS.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `man`; alternatives might be `individual`, `people`, `person`
* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Outdated references

Reference `[RFC7489]` to `RFC7489`, which was obsoleted by `RFC9989`,
`RFC9990`, and `RFC9991` (this may be on purpose).

Reference `[RFC822]` to `RFC822`, which was obsoleted by `RFC2822` (this may be
on purpose).

### Grammar/style

#### "Table of Contents", paragraph 1
```
order to promote interoperability amongst senders, receivers, and intermediar
                                  ^^^^^^^
```
Do not mix variants of the same word ("amongst" and "among") within a single
text.

#### Section 1.1, paragraph 1
```
gainst spam and other attacks. In addition SMTP (and Message Format) extensio
                                  ^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "addition".

#### Section 2.2, paragraph 1
```
have never been widely used nor well supported. In 2013 [RFC7085] found 18 TL
                                ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 2.4, paragraph 8
```
d header field) and "local-part" (left hand side of email addresses). For ex
                                  ^^^^^^^^^
```
Did you mean the adjective "left-hand"?

#### Section 3.3, paragraph 1
```
of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementatio
                                ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 4.3, paragraph 7
```
h as non-textual message bodies, multi-part message bodies, and the use of c
                                ^^^^^^^^^^
```
This word is normally spelled as one.

[Ballot discuss]
** The guidance and observations on the use of confidentiality are not self-consistent and lead to risky guidance.

(a) Section 2.4 says “As a result, the following extensions MUST be supported by SMTP senders and receivers: *  Secure SMTP over Transport Layer Security [RFC3207]” – I take this to mean all senders and receivers conformant to this document must have support for STARTTLS

(b) Section 6.1.2 says “Most modern implementations of SMTP support this [opportunistic encryption] method and so a substantial portion of email traffic is encrypted during its time transiting from the client to the next server.” – I take this to mean that there are a minority (since this text says “most”) of “modern implementations” which don’t conform to this draft, since conformance means supporting STARTTLS.  This language appears to be consistent with (a) acknowledging that implementers and operators may make choices contrary to the RFC’s guidance.

(c) Section 6.3 says “  … and deployments should require use of an effective confidentiality mechanism, with SMTP AUTH such as TLS.” – I take this to mean servers and receivers should have some kind of confidentiality mechanism.  We know from the constraints imposed by (a), every conformant sender and receiver minimally supports STARTTLS.  This language is consistent with (a).

(d) Section 6.5 say “there are many implementations of SMTP that are still in widespread use in both private and Internet-connected networks that either do not support over-the-wire confidentiality or that are configured to not use it when sending messages” – This may be true, but these implementations are already non-conformant to this draft on the requirements set out in (a). This is the first introduction of consideration for “private networks”.

(e) Section 6.5 says “In order to maximize interoperation and avoid refusal of legitimate    messages, SMTP-receivers MUST NOT require SMTP-senders to use over-the-wire confidentiality mechanisms.  While that provision is extremely important to promote delivery of legitimate messages whenever possible, mechanisms that provide  confidentiality are still strongly preferred when they are feasible.”  -- This is the start of my confusion. Why can’t SMTP-receivers require over-the-wire confidentiality?  Support for STARTTLS is already mandatory to support.  From the perspective of this draft, each sender has at least one viable confidentiality approach.  If a sender doesn’t support STARTTLS, then it is already not conformant to this draft.  It isn’t clear why normative, interoperability language is being written to cover non-compliant behavior on this issue.  If this is about tracking reality, why is it acceptable to require STARTTLS in (a), but then note in (b) and (d) that this isn’t really supported in certain instances.

** As Section 6.5 alludes to both private and public networks sending email (see text quoted in (d) and (e) above, and my next discuss point on this applicability statement being unclear in applicable domain), why are there interoperability concerns on a private network requiring weak security practices?  Why can’t the private network operator have autonomy to set local policies, to include implementation of confidentiality?

** Consistent with Deb Cooley’s DISCUSS position, this document is leaving a security issue by allowing clear-text SMTP for conformant end-points.  Rather than allowing local policy to accept risk (e.g.,“SHOULD use a confidentiality mechanism”) or enabling the feature they are already required to support (aka, “MUST use a confidentiality mechanism”), this text is taking the choice out of the hands of operators who want to be conformant and forcing risky behavior (aka, “MUST NOT require SMTP-senders to use over-the-wire confidentiality mechanisms”).  This is inconsistent with

** The “applicability domain” element of an applicability statement seems to be missing.

  This document is an Applicability Statement [RFC2026], Section 3.2
  that provides guidance in the use of the Internet's core email
  specifications, the Simple Mail Transfer Protocol (SMTP)

What is the “applicability domain” of this set of recommendations?  Is it the “public internet”?  Do they apply to a closed intranet? 
Sections like the following refer to the public internet, but others do not.  There is also a reference to private networks.  To what kind of networks does this document apply?

-- Section 2.2.  Use of Address Literals, “The address-literal ABNF non-terminal is used in various places in [I-D.ietf-emailcore-rfc5321bis] grammar.  However, for SMTP  connections over the public internet, …”

-- Section 4.3.  “Where those other rules allow syntax variations that the IETF specifications cited above do not, those variations should be avoided because they are unlikely to be accepted across the Internet email environment.”

-- Section 6.5.  “That said, there are many implementations of SMTP that are still in widespread use in both private and Internet-connected networks”

[Ballot comment]
Thank you to Vijay Gurbani for the GENART review.

I support the DISCUSS positions of Deb Cooley and Ketan Talaulikar.

** Section 2.3

2.3.  Use of Addresses in Top-Level Domains
  Hence, for reliable service, mail SHOULD NOT use addresses that
  contain single label domains.

An unqualified SHOULD NOT. When is it appropriate to use such addresses?

** Section 2.4
  Similarly, the following extensions SHOULD be supported by SMTP
  senders and receivers:
  *  Command Pipelining [RFC2920]
  *  Internationalized Email [SMTPUTF8]
  Delivery Status Notifications [RFC3461] requests, while recommended
  and useful if supported, have not been widely implemented and
  deployed.  Mail systems that send such requests should be prepared
  for systems that receive them to not recognize or support them.  Note
  that this extension for notification requests is distinct from the
  format of notifications defined in [RFC3464] and [RFC6533], and the
  special media type defined in [RFC6522].  All of those SHOULD be
  supported.

-- “SHOULD” both senders and receivers support RFC3461, RFC3464, RFC6533, and RFC6522?  The text isn’t clear.  For RFC2920 and SMTPUTF8, a crisper statement of applicability for the sender and receiver is made.

-- These are all “unqualified SHOULDs” on implementers.  When can this advice be ignored?

** Section 3.1
  In particular, use of
  empty quoted strings is discouraged in "received-token" (a component
  of a Received header field) and "local-part" (left hand side of email
  addresses).

What does this guidance mean relative to interoperability?  Discouraged isn’t even a defined key word.  This can be ignored, then?  Should s/discouraged/SHOULD NOT/

** Section 3.3.  Unqualified SHOULD
  When performing such functions, the MUA SHOULD:
  *  Remove all header fields unknown to the MUA
  *  Remove any header fields that are only pertinent to the transport
      of the original message, such as trace header fields (see
      Section 3.6.7 of [I-D.ietf-emailcore-rfc5322bis])

When should this not be done by the MUA?

** Section 3.4

3.4.  Group Syntax
  "Group" syntax [I-D.ietf-emailcore-rfc5322bis] [RFC6854] has been a
  long-standing construct in the specification, going back to RFC 822
  [RFC822], but it has had little use in all that time.  It is
  therefore possible that use of it in a message will conform with the
  specifications but not be supported by some implementations.

What is an implementer/operator supposed to do with this guidance beyond what is already documented in other RFCs?  What novel guidance is provided here?

** Section 4.1.  It isn’t clear how an implementer is supposed to interpret this section.  On the one hand the text points out that local-part “MUST be treated as case sensitive” but then roughly says ignore that advice if you want “maximum interoperability”.  Are there other places where normative, mandatory guidance should be ignored for “maximum interoperability”?

** Section 4.1
  Since only the final
  delivery system can properly interpret the local-part of an address,
  originating and transit/relay mail systems are discouraged from
  making any assumptions as to address equivalence or from making any
  changes to local-parts containing such delimiters.

Same feedback as in Section 3.1.  What does discouraged mean?  When is it acceptable to modifier content with delimiters?

** Section 5.
  As a
  result, IMF generators and parsers are expected to support MIME.

What does “expected” mean?  Is this MIME support mandatory?

[Ballot comment]
Section 6.5, Confidentiality Requirements, MUST items and MUST NOT paragraph:

708 >    1.  confidentiality (for example, the STARTTLS extension) MUST be
709 >        implemented by SMTP servers in order to at least provide over-
710 >        the-wire confidentiality during an individual SMTP exchange, and
711 >
712 >    2.  confidentiality MUST be used when sending if it is available and
713 >        accepted by the receiving server.
714 >
715 >    That said, there are many implementations of SMTP that are still in
716 >    widespread use in both private and Internet-connected networks that
717 >    either do not support over-the-wire confidentiality or that are
718 >    configured to not use it when sending messages.  Hence, receiving
719 >    server implementations will often be expected to be capable of
720 >    receiving such messages.
721 >
722 >    Therefore:
723 >    In order to maximize interoperation and avoid refusal of legitimate
724 >    messages, SMTP-receivers MUST NOT require SMTP-senders to use over-
725 >    the-wire confidentiality mechanisms.  While that provision is
726 >    extremely important to promote delivery of legitimate messages
727 >    whenever possible, mechanisms that provide confidentiality are still
728 >    strongly preferred when they are feasible.

Setting aside Deb Cooley's DISCUSS on the appropriateness of the "MUST NOT"
itself, my concern is about the internal logical gap the text leaves open.
Item 2 already requires senders to use TLS whenever it is "available and
accepted by the receiving server." When that condition is met, the sender is
under a MUST obligation. The "MUST NOT require" in the final paragraph is
therefore most relevant to the case where the sender lacks TLS capability
altogether. The text does not state this explicitly: it says SMTP-receivers
MUST NOT require confidentiality without explaining that the underlying
rationale is to accommodate senders that are incapable of providing it. As
written, a reader could reasonably (if incorrectly) infer that the MUST NOT
overrides Item 2 -- i.e., that a sender that has TLS capability may nonetheless
forgo it because the receiver is forbidden from insisting on it. I believe
making the scope of the MUST NOT explicit (e.g., "...in order to ensure
delivery from senders that do not support over-the-wire confidentiality") would
reduce the confusion that has surrounded this section through multiple
revisions.

---

Section 9, Security Considerations:

751 >    Security and privacy considerations are discussed throughout this
752 >    document as they pertain to the referenced specifications.  Special
753 >    note should be taken of the interaction between confidentiality and
754 >    authentication mechanisms that are applicable to Internet links and
755 >    therefore potentially sensitive to the multi-hop design of SMTP.
756 >    Unless the relevant messages and mechanisms are protected from
757 >    tampering or content exposure on systems that are the endpoints of
758 >    those links, the security of the mechanisms depends on trust in those
759 >    intermediate endpoints.

For a document that imposes MUST-level security requirements (implement TLS,
use TLS when sending, never send cleartext credentials without TLS), I find
this five-sentence section inadequate. Per RFC 3552, security considerations
should enumerate the threats being mitigated and the residual risks remaining
after the prescribed mitigations are applied. In my view, this section should
at minimum:

(a) identify the threats that the MUST requirements address (e.g.,
passive monitoring per BCP 188, active MITM attacks against opportunistic TLS),

(b) describe the residual risk when the MUST NOT for receivers accommodates
cleartext delivery (an unprotected link in the SMTP hop chain remains fully
exposed), and

(c) note what this document does not protect (e.g., confidential
storage at intermediate MTAs, end-to-end content protection). Deb Cooley has
offered to help with language here; I would welcome that addition.

---

Section 6.2, Message-Level Authentication, DMARC bullet:

643 >    *  DMARC [RFC7489] relies on SPF and DKIM to allow for validation of
644 >        the domain in the visible From header.

I concur with Gunter Van de Velde's comment here.

---

Section 3.3, Reuse of Existing Messages, first SHOULD bullet:

336 >    When performing such functions, the MUA SHOULD:
337 >
338 >    *  Remove all header fields unknown to the MUA

The advice to remove ALL unknown header fields strikes me as broader than
intended. Many deployed email systems carry extension header fields (for
filtering, classification, threading, or protocol purposes) that are not
understood by every MUA but play a role in the delivery or handling ecosystem.
Blanket removal would silently discard these fields, potentially breaking
downstream processing. The second bullet already handles trace fields
specifically. I would suggest the first bullet be narrowed -- for example, to
fields with transport semantics or privacy implications that are meaningless or
potentially harmful in the context of a re-used message -- or that a brief
rationale be added explaining why removal of all unknown fields is nonetheless
the right policy here.

---

Section 5, Use of Multipurpose Internet Mail Extensions (MIME):

503 >    MIME features such as non-textual message bodies, multi-part message
504 >    bodies, and the use of character sets other than US-ASCII in message
505 >    bodies have become nearly ubiquitous in contemporary email.  As a
506 >    result, IMF generators and parsers are expected to support MIME.

The phrase "are expected to support MIME" uses informal language where a formal
BCP 14 requirement level seems intended. Since RFC 2045 is already listed as a
normative reference, I would suggest replacing "are expected to" with "MUST" or
"SHOULD" (depending on the intended strength) to be consistent with the rest of
the document's normative guidance.

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

There is the point about normative references that Gunter has raised in his ballot as a comment. I am bringing it up as a discussion point while trying to list (but there were too many and I could not finish) the references that should be classified as normative based on my reading (I could be wrong, happy to be corrected).

[I-D.ietf-emailcore-rfc5321bis]
[I-D.ietf-emailcore-rfc5322bis]
[RFC2034]
[RFC2920]
[RFC3207]
[RFC3464]
[RFC4954]
[RFC5248]
... I apologize but I ran out of time at this point :-(

I trust the authors will review the list and correct the classification.

[Ballot comment]
I would also like to request the authors to cross-check if some the following (and there may be others) should use their BCP14 keyword equivalents.

"This is particularly important for software that validates user-input fields, where case changes are tempting, but must be avoided."

"This is actually just a special case of a principle, discussed in Section 2.3.11 of [I-D.ietf-emailcore-rfc5321bis] and elsewhere, that nothing other than the final delivery system should attempt to interpret or alter the local-part of an address. In particular, they MUST NOT:" .... please consider if the first sentence is framed as a SHOULD NOT for other that the final delivery system.

"As already specified in Section 4 of RFC 4954, cleartext credentials MUST NOT be sent without TLS, and deployments should require use of an effective confidentiality mechanism, with SMTP AUTH such as TLS." ... perhaps SHOULD or RECOMMENDED instead of the should?

[Ballot discuss]
Section 6.5, last para:  I understand that this is the hotly contested part of the specification. In this day and age, having strong language for not protecting traffic across the wire is irresponsible (my opinion, but it is why they pay me).  I'm objecting to the strength of the language, not the existence of a 'way out of the situation' language.

My comments/options are these:
- I do think that #1 and #2 above are capable of standing alone, one could merely delete the last para
- I think that the 'MUST NOT' is incredibly strong and a 'softer' term will also work, be that a 'MAY NOT' or something 'not BCP 14'ish like 'can not'. 
- The other tact to take here is to turn it around and encourage SMTP-senders to 'SHOULD' implement the capability to encrypt (or protect) messages (with the second to last para providing rationale).

Section 9: Of course, this might be the perfect (better?) place to explain the risk that a SMTP-sender takes by not implementing the capability to encrypt (or otherwise protect) the data as it traverses the Internet.  I would be happy to help with this language.

[Ballot comment]
Thanks to Shivan Sahib for their multiple secdir reviews.

Section 6.1.2:  s/man-in-the-middle/person-in-the-middle.

Section 6.1.3:  Is this specification encouraging support for these protocols?  If so, it is hard to discern from the current text.  A simple change to the last sentence would make it more obvious.  Perhaps '...in this section is increasing, and encouraged, but is not yet...'.  Of course, I assume that reducing the opportunity of a 'person-in-the-middle' attack is a good thing.

References:  I suggest leaving a note for the RFC Editor to replace RFC8446 with RFC9846 (draft-ietf-tls-8446bis, currently in Auth48) should it be published prior to this specification. 

References:  While RFC9325 is listed, it might be more prudent to list BCP195, which loops in deprecations and will mandate TLS1.3 when draft-ietf-uta-require-tls13 (in Auth48) is published.

[Ballot comment]
Hi Authors, WG,

# Gunter Van de Velde, RTG AD, comments for draft-ietf-emailcore-as-29

# Normative reference classification looks wrong.
The draft has only RFC2026, RFC2045, RFC2119, and RFC8174 as normative references. Section 2.4 says SMTP senders and receivers MUST support STARTTLS/RFC3207 and 8BITMIME/RFC6152, and SHOULD support PIPELINING/RFC2920 and SMTPUTF8. These are currently informative references. That seems incorrect.

# Core protocol references are informative, but the AS depends on them normatively.
The document is an Applicability Statement for SMTP and IMF and repeatedly uses 5321bis/5322bis as the basis for syntax and behavior. They are currently informative. Given the AS makes recommendations that depend on those specs, I would expect both I-D.ietf-emailcore-rfc5321bis and I-D.ietf-emailcore-rfc5322bis to be normative.

# Section 2.1: EHLO domain reverse/forward matching guidance is operationally common, but “may refuse” is lowercase. If intended as protocol advice, consider MAY.

# Section 2.3: The 2025 TLD MX numbers are empirical. Consider citing the source or method, not only RFC7085.

# Section 3.1: “empty quoted string” should probably be “empty quoted strings” in one sentence.

# Section 3.3: “Remove all header fields unknown to the MUA” may be too strong operationally; this risks deleting extension fields that should be preserved. Consider “fields that are unsafe or not understood in this reuse context”.

# Section 4.3: “implementations are encouraged to strip trailing dots” could conflict with “do not alter local-parts” principles, though this is domain-part only. Consider saying this applies only during input normalization before SMTP use, not in transit.

# Section 5: If IMF generators/parsers are “expected to support MIME”, RFC2045 as normative is OK, but MIME is more than RFC2045. Consider whether RFC2046/2047/2048/2049 should be cited.

# Section 6.2: DMARC reference should likely be updated from RFC7489 to RFC9989.

Kind Regards,
Gunter Van de Velde
Routing Area Director

Request for IETF Last Call review by SECDIR Completed: Has Issues. Reviewer: Shivan Sahib. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-04-27):

From: The IESG
To: IETF-Announce
CC: andy@hxr.us, draft-ietf-emailcore-as@ietf.org, emailcore-chairs@ietf.org, emailcore@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Applicability Statement for IETF Core Email Protocols) to Proposed Standard

The IESG is conducting a supplementary Last Call for draft-ietf-emailcore-as-28.txt.

This supplementary Last Call is for the sole purpose of verifying rough consensus exists for issues which were raised during the Last Call for draft-ietf-emailcore-as-26. The EMAILCORE working group has deliberated and made changes to this applicability statement, particularly to Section 6.5, within the scope of the group's charter to capture current email practices.

The diff between the two versions may be found here:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-emailcore-as-26&url2=draft-ietf-emailcore-as-28&difftype=--html

Please focus your feedback on the changes between -26 to -28 with respect to the bounds of the EMAILCORE charter.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-04-27. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Request for IETF Last Call review by SECDIR Completed: Has Issues. Reviewer: Shivan Sahib. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-01-06):

From: The IESG
To: IETF-Announce
CC: andy@hxr.us, draft-ietf-emailcore-as@ietf.org, emailcore-chairs@ietf.org, emailcore@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Applicability Statement for IETF Core Email Protocols) to Proposed Standard


The IESG has received a request from the Revision of core Email
specifications WG (emailcore) to consider the following document: -
'Applicability Statement for IETF Core Email Protocols'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-01-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Electronic mail is one of the oldest Internet applications that is
  still in very active use.  While the basic protocols and formats for
  mail transport and message formats have evolved slowly over the
  years, events and thinking in more recent years have supplemented
  those core protocols with additional features and suggestions for
  their use.  This Applicability Statement describes the relationship
  among many of those protocols and provides guidance and makes
  recommendations for the use of features of the core protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emailcore-as/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

NOTE: This document should become part of C540.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached broad consensus of the WG.  The WG includes about a dozen "full-time" participants and a number of others that also contribute with less regularity.

There were some issues that were raised but ultimately determined to be in the rough.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

In the shepherd's opinion, consensus was comfortable (i.e., not particularly rough), but in some cases it took quite some time to get there.  A few of the issues raised were occasionally confusing to the bulk of the WG, which did a diligent job trying to understand and propose compromises.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There are no threats of appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Many of the practices identified by this document are informed by existing implementations and common practices of a number of implementations of the base documents and the other protocols referenced by this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No such external or cross-WG reviews are warranted.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document does not make use of MIBs, YANG, media types, or URIs, beyond those already registered by the standards track documents referenced.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG is present.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal languages are used here.  There's a reference to ABNF, but none is presented.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all of these.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The Email topics in the ART Area list are considered by this group, but there's nothing outstanding.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document is an Applicability Statement, and as such is seeking Proposed Standard status (RFC 2026, Section 3.2).  This is properly reflected in the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I polled the authors off-list to confirm no outstanding BCP79 declarations regarding the material in this document, and they so affirmed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The authors have also so affirmed via private email.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Two nits of interest were identified:

  == Missing Reference: 'RFC6530' is mentioned on line 413, but not defined

  == Missing Reference: 'RFC5891' is mentioned on line 405, but not defined

This seems to be a fault in IDNits itself.  The document, for example, does reference "[RFC6530]", but that RFC is actually part of a compound (i.e., multi-document) reference called "[SMTPUTF8]".  I'm not sure what guidance there might be to clear this.  I've made some suggestions on the list.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, these look fine.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are public.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no normative downward references that need to be registered.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No, this is the last in this cluster.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not update the status of any other document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA actions in this document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA actions in this document.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

NOTE: This document should become part of C540.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached broad consensus of the WG.  The WG includes about a dozen "full-time" participants and a number of others that also contribute with less regularity.

There were some issues that were raised but ultimately determined to be in the rough.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

In the shepherd's opinion, consensus was comfortable (i.e., not particularly rough), but in some cases it took quite some time to get there.  A few of the issues raised were occasionally confusing to the bulk of the WG, which did a diligent job trying to understand and propose compromises.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There are no threats of appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Many of the practices identified by this document are informed by existing implementations and common practices of a number of implementations of the base documents and the other protocols referenced by this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No such external or cross-WG reviews are warranted.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document does not make use of MIBs, YANG, media types, or URIs, beyond those already registered by the standards track documents referenced.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG is present.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal languages are used here.  There's a reference to ABNF, but none is presented.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all of these.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The Email topics in the ART Area list are considered by this group, but there's nothing outstanding.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document is an Applicability Statement, and as such is seeking Proposed Standard status (RFC 2026, Section 3.2).  This is properly reflected in the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I polled the authors off-list to confirm no outstanding BCP79 declarations regarding the material in this document, and they so affirmed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The authors have also so affirmed via private email.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Two nits of interest were identified:

  == Missing Reference: 'RFC6530' is mentioned on line 413, but not defined

  == Missing Reference: 'RFC5891' is mentioned on line 405, but not defined

This seems to be a fault in IDNits itself.  The document, for example, does reference "[RFC6530]", but that RFC is actually part of a compound (i.e., multi-document) reference called "[SMTPUTF8]".  I'm not sure what guidance there might be to clear this.  I've made some suggestions on the list.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, these look fine.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are public.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no normative downward references that need to be registered.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No, this is the last in this cluster.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not update the status of any other document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA actions in this document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA actions in this document.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

NOTE: This document should become part of C540.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The document reached broad consensus of the WG.  The WG includes about a dozen "full-time" participants and a number of others that also contribute with less regularity.

There were some issues that were raised but ultimately determined to be in the rough.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

In the shepherd's opinion, consensus was comfortable (i.e., not particularly rough), but in some cases it took quite some time to get there.  A few of the issues raised were occasionally confusing to the bulk of the WG, which did a diligent job trying to understand and propose compromises.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

There are no threats of appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Many of the practices identified by this document are informed by existing implementations and common practices of a number of implementations of the base documents and the other protocols referenced by this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No such external or cross-WG reviews are warranted.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document does not make use of MIBs, YANG, media types, or URIs, beyond those already registered by the standards track documents referenced.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

No YANG is present.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No formal languages are used here.  There's a reference to ABNF, but none is presented.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes to all of these.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

The Email topics in the ART Area list are considered by this group, but there's nothing outstanding.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

This document is an Applicability Statement, and as such is seeking Proposed Standard status (RFC 2026, Section 3.2).  This is properly reflected in the datatracker.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I polled the authors off-list to confirm no outstanding BCP79 declarations regarding the material in this document, and they so affirmed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The authors have also so affirmed via private email.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Two nits of interest were identified:

  == Missing Reference: 'RFC6530' is mentioned on line 413, but not defined

  == Missing Reference: 'RFC5891' is mentioned on line 405, but not defined

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

No, these look fine.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are public.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are no normative downward references that need to be registered.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

No, this is the last in this cluster.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not update the status of any other document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

There are no IANA actions in this document.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

There are no IANA actions in this document.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/