Last Call Review of draft-billon-expires-08
review-billon-expires-08-genart-lc-sparks-2022-12-16-00

Request Review of draft-billon-expires
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2022-12-27
Requested 2022-11-29
Authors Benjamin BILLON , John R. Levine
I-D last updated 2022-12-16
Completed reviews Artart Last Call review of -06 by Barry Leiba (diff)
Opsdir Last Call review of -06 by Carlos Pignataro (diff)
Genart Last Call review of -08 by Robert Sparks (diff)
Secdir Last Call review of -06 by Chris M. Lonvick (diff)
Secdir Last Call review of -08 by Chris M. Lonvick (diff)
Artart Last Call review of -07 by Barry Leiba (diff)
Opsdir Last Call review of -08 by Tim Chown (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-billon-expires by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/VLwwmGq12P1xAUsOZMKywLw38fM
Reviewed revision 08 (document currently at 09)
Result Ready
Completed 2022-12-16
review-billon-expires-08-genart-lc-sparks-2022-12-16-00
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://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-billon-expires-08
Reviewer: Robert Sparks
Review Date: 2022-12-16
IETF LC End Date: 2022-12-27
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a proposed standard RFC

The last call discussion of this document is surprisingly voluminous, but my
individual opinion is that no further change is needed.

To me the document is clear and at least one implementation exists.

It's interesting to note that as of -08 there are only two non-boilerplate
sentences using BCP 14 keywords:

*  Message creators **MUST NOT** include more than one Expires header field in
the message they send. *  If there is more than one Expires header field then
message readers **SHOULD** act as if no Expires header field is present.

(unless the software I have that extracts those has a bug).