Hello,
At 11:54 PM 20-03-2025, The IESG wrote:
This supplementary Last Call is for the sole purpose of verifying
rough consensus exists for issues which were raised by and as a
result of the SECDIR review of this document that have been
addressed in version -42.
The SECDIR review can be found here:
https://datatracker.ietf.org/doc/review-ietf-emailcore-rfc5321bis-31-secdir-lc-eastlake-2024-10-11/
...and the WG's response to it is a long thread that began here:
https://mailarchive.ietf.org/arch/msg/emailcore/EHs584ejRsJ29M1X1RO1-zt5IV0/
...and a diff between the SECDIR-reviewed version and the current
version can be found here:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-emailcore-rfc5321bis-38&url2=draft-ietf-emailcore-rfc5321bis-42&difftype=--html
Please limit your feedback to responding to this specific question.
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.
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.
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)?
Would it be okay to have a technical specification about core
protocols which do not have a normative reference to those core protocols?
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.
Regards,
S. Moonesamy
1. https://www.rfc-editor.org/info/rfc937
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
