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 < nore...@ietf.org> 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. > > > >
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
