Reviewer: Robert Sparks Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-httpapi-deprecation-header-06 Reviewer: Robert Sparks Review Date: 2024-08-29 IETF LC End Date: 2024-09-06 IESG Telechat date: Not scheduled for a telechat Summary:Almost Ready for publication as a Proposed Standard (?) RFC Why is this standards track? The shepherd's writeup explanation of "that makes sense since it defines a new HTTP header field" seems at odds with RFC8594 being Informational. Should that have been standards track? Generally, the document would benefit from an editorial pass further clarifying when it is talking about an application or a developer. There are many points where it says application or client when it means developer. Some key instances: * Introduction: "informs applications about the risk" * Security considerations "Applications consuming the resource SHOULD check the referred resource documentation to verify authenticity and accuracy." * Security considerations "Therefore, applications consuming the resource SHOULD, if possible, consult the resource developer to discuss potential impact due to deprecation and plan for possible transition to a recommended resource(s)" There is a contradiction between section 5's "Deprecated resources SHOULD keep functioning as before" and the Security Consideration's "Deprecated resources MUST function (almost) as before," In both cases, "function as before" is not really what you mean. "function as they would have without sending the deprecation header" is closer. As written, (particularly if the MUST above is what you intend), this puts an unverifiable requirement on the resource. I suggest changing the language similar to what I suggested you mean. Or, better, step back and reformulate this as a simple statement that the presence of a Deprecation header is not meant to signal a change in the meaning or function of a resource in the context of this response, and avoid using 2119 keywords. I realize that Appendix A won't appear in the resulting RFC, but the drafts will still be in the archive. Calling an internet draft an implementation and an organization is just strange. Revising the draft to use a separate section (or just a sentence) to say draft-loffredo-regex-rdap-jcard-deprecation is a specification that says to use this mechanic would make more sense than listing it as an implementation. Since the WG felt using structured fields was important for this header, consider creating a Structured-Sunset header field. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
