Hello Robert,
Thanks for your review comments. We captured your review notes in https://github.com/ietf-wg-httpapi/deprecation-header/issues/35 and we have addressed those. Draft 08 published today https://datatracker.ietf.org/doc/draft-ietf-httpapi-deprecation-header/ incorporates all your comments per our understanding. Let me know if something is missed.
regards,
sanjay
On Thu, Aug 29, 2024 at 10:21 AM Robert Sparks via Datatracker <noreply@xxxxxxxx> wrote:
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
