John C Klensin wrote:
However, while it is apparently not final and still has not
appeared in the tracker (see
https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/),
the apparent intent of the IESG, reflected in the ballot at
https://datatracker.ietf.org/idtracker/ballot/2471/, is to
add an IESG note to the front of the document
That's how those RFC-editor and IESG notes are prepared, they
appear in the (draft) approval mail at the end of the ballot.
It is one of two weak points (the other being AUTH48) with
drafts. But authors are free to reject it in AUTH48 by not
signing an annotated draft.
For RFC 4408 folks caught an "RFCed note" attempt to remove
an absolutely critical NOT RECOMMENDED, and rejected it.
After that it popped up again as "IESG note" and went to an
IAB review. The IAB decided that conflicting experiments
offering a convoluted IESG note "opt-out" for participants
of the 1st experiment not interested in the 2nd experiment
are no issue.
With that on public record the case was closed and the RFC
published (with the complete revised IESG note, see below).
the IESG has made no attempt to engage in a dialog on the
subject of whether a note or this sort should be added, or
about what it should contain
Yes, interested folks have to check the proposed approval or
read the final announcement, and they also have to check the
final AUTH48 outcome. Even a good faith "RFC-editor note"
can introduce massive side-effects like blocking RFCs 4645
and 4646 for many months until RFC 4647 was ready.
while Section 6.1.2 of RFC 2026 contains an extended
discussion of the IESG changing categories, forming WGs,
etc., it appears clear that the IESG is to "approve or
disapprove", not to start adding text reflecting its own
observations, observations that may or may not represent
community consensus.
Did you ever read the rather long IESG note in RFC 4408 ?
| there is no general technical consensus and efforts to
| reconcile the two approaches have failed
= After the WG had consensus that the two approaches are
incompatible it was terminated in violation of RFC 2418
| these documents have not received full IETF review
= a request for an IETF Last Call was rejected by the IESG
| Note that the Sender ID experiment may use DNS records
| that may have been created for the current SPF experiment
| or earlier versions in this set of experiments.
= Three Sender ID ABSTAINs failed to reach 1/3 for a DO NOT
PUBLISH by one vote (IIRC)
| Depending on the content of the record, this may mean that
| Sender-ID heuristics would be applied incorrectly to a
| message. Depending on the actions associated by the
| recipient with those heuristics, the message may not be
| delivered or may be discarded on receipt.
= A 100% accurate description of the problem.
| Participants relying on Sender ID experiment DNS records
| are warned that they may lose valid messages in this set
| of circumstances.
= That is about receivers applying the Sender ID algorithm
on an SPF polic; they may lose legit inbound mails. This
statement apparently missed the point in two dimensions.
| aParticipants publishing SPF experiment DNS records should
| consider the advice given in section 3.4 of RFC 4406 and
| may wish to publish both v=spf1 and spf2.0 records to avoid
| the conflict.
= Sender ID offers a weird "opt-out" from its own bugs; it
is no problem to publish more than one TXT record; about
a million (back in 2006) of existing SPF publishers will
read IESG notes.
The next eight lines are mostly unrelated to RFC 4408, they
note that RFC 4406 can be not published on standards track
"as is" due to interoperability issues with RFC 822 + 2822.
(Among others, there are also issues with RFC 4409)
The longest IESG note I've ever seen in IETF RFCs (exactly
the same text went into RFCs 4405, 4406, and 4407).
Advice or instructions welcome.
Readers will hopefully see that using real domains or mail
addresses in examples is not recommended, as it can cause
harm or other unexpected (SEO) effects.
At some point in time, e.g., in a next 2026bis round, the
"IESG notes" deserve a critical review. They are free to
publish their thoughts in separate documents, unsolicited
annotations sometimes annoy authors and interested users.
Frank