[Gen-art] Genart last call review of draft-wilde-sunset-header-07

Jari Arkko <jari.arkko@piuha.net> Sat, 27 October 2018 07:36 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E265130E01; Sat, 27 Oct 2018 00:36:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jari Arkko <jari.arkko@piuha.net>
To: <gen-art@ietf.org>
Cc: draft-wilde-sunset-header.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154062576395.5617.8725497285559940981@ietfa.amsl.com>
Date: Sat, 27 Oct 2018 00:36:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/4kOyF6cnF3OwAjeHLoNg-yOouMA>
Subject: [Gen-art] Genart last call review of draft-wilde-sunset-header-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Oct 2018 07:36:04 -0000

Reviewer: Jari Arkko
Review result: Ready with Issues

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


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

Major issues:

Minor issues:

The section on relation link type discusses who may be reading the linked

   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.