[Gen-art] Re: Genart last call review of draft-ietf-httpapi-deprecation-header-06

[Robert Sparks <[e-mail]>]

Thanks - I'm fine with this version. It would be good for fresher eyes 
should watch for other improvements like this as it finishes review.

RjS

On 9/12/24 3:36 PM, Sanjay Dalal wrote:
> Ah, I missed that. Sorry about that. Thanks for your patience.
>
> https://github.com/ietf-wg-httpapi/deprecation-header/commit/a32eb7f65cddd8a4dc6ff1899814ae3756710e66
>
> https://github.com/ietf-wg-httpapi/deprecation-header/blob/main/draft-ietf-httpapi-deprecation-header.md
>
> On Thu, Sep 12, 2024 at 1:25 PM Robert Sparks <[e-mail]> 
> wrote:
>
>     Thanks - its going in the right direction I think.
>
>     Please look again where you are saying applications will make an
>     educated guess and if that's really _software_ maybe choose
>     different words than "educated guess"? Software can't do that.
>
>     RjS
>
>     On 9/12/24 3:20 PM, Sanjay Dalal wrote:
>>     Hello Robert,
>>
>>     Thanks for clarifying. Take a look at
>>     https://github.com/ietf-wg-httpapi/deprecation-header/commit/5d4a4f65175001cea293204c9e245388f1552d45.
>>     I went ahead and re-looked where a human would be needed and
>>     added "developer" over there.
>>
>>     If you are ok now, I will mark this issue resolved. We will
>>     publish the draft once we have addressed comments we may receive
>>     from other reviewers.
>>
>>     regards,
>>     sanjay
>>
>>     On Thu, Sep 12, 2024 at 9:34 AM Robert Sparks
>>     <[e-mail]> wrote:
>>
>>         Thanks Sanjay -
>>
>>         I think there's still some tension to resolve on who has
>>         agency in several places. With the description in section 6.2
>>         in mind (particularly at "intended for human consumption",
>>         please look again at the places you've changed "client" to
>>         "client application". You're still talking in places of
>>         having the application do things an application can't do.
>>         Only the application developers can do them.
>>
>>         What does it mean for an application to make an educated guess?
>>
>>         How does an application inspect (and make sense of) a home
>>         document?
>>
>>         In both of those places, and others, you are talking about
>>         humans doing things, not applications.
>>
>>         RjS
>>
>>         On 9/12/24 11:19 AM, Sanjay Dalal wrote:
>>>         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 <[e-mail]> 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.
>>>
>>>
>>>