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 . Document: draft-wilde-sunset-header-?? Reviewer: Jari Arkko Review Date: 2018-10-26 IETF LC End Date: 2018-11-20 IESG Telechat date: Not scheduled for a telechat Summary: This is a well-written, understandable and useful piece of specification. Thanks for writing it. I had a couple of minor observations, but otherwise the draft is ready to be published. Major issues: Minor issues: The section on relation link type discusses who may be reading the linked material: This specification places no constraints on the scope or the type of the linked resource. The scope can be for a resource or for a service. The type is determined by the media type of the linked resource, and can be targeted at humans, at machines, or a combination of both. That's fine, but at the same time my understanding is that there is no media type today that would actually be machine readable and usable for your purpose? Is this so? If I cannot write code today for a machine to do anything with the linked resource, maybe that's something that you'd want to say. And you probably don't want to blindly load and use the load-this-executable-and-all-your-linking-problems-are-history media type, either :-) The security considerations section does not mention that there might be cases where the lifetime information could be sensitive. Are there such cases? The only example of that I can come with is that a fixed data retention rule would obviously also reveal the time that the organisation in question has learned about the data in question, which might be sensitive in some cases. Nits/editorial comments: The example section could perhaps demonstrate the use of the sunset relation in addition to the header field.