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

[Erik Wilde <[e-mail]>]

hello jari.

thanks a lot for the review!

On 2018-10-27 01:36, Jari Arkko wrote:
> 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.

that's great to hear. i will make changes according to your review, and 
publish a new version (-08) later this week.

> 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 main idea was that the policy probably would be more often 
documented than described in a fully machine-understandable format.

but i do understand you concerns. i have done two things. right 
underneath the sentence you quoted, i have added the following:

"If the linked resource does provide machine-readable information, 
consumers should be careful before acting on this information. Such 
information may, for example, instruct consumers to use a migration rule 
so that sunset resources can be accessed at new URIs. However, this kind 
of information amounts to a possibly large-scale identity migration of 
resources, so it is crucial that the migration information is authentic 
and accurate."

i have also added a paragraph about the same issue to the security 
considerations section:

"In cases where a sunset policy is linked by using the sunset link 
relation type, clients should be careful about taking any actions based 
on this information. It should be verified that the information is 
authentic and accurate. Furthermore, it should be tested that this 
information is only applied to resources that are within the scope of 
the policy, making sure that sunset policies cannot "hijack" resources 
by for example providing migration information for them."

> 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.

that's a very good point, i have added that as the very first paragraph 
of the security considerations.

"Generally speaking, information about upcoming sunsets can leak 
information that otherwise might not be available. For example, a 
resource representing a registration can leak information about the 
expiration date when it exposes sunset information. For this reason, any 
use of sunset information where the sunset represents an expiration or 
allows the calculation of another date (such as calculating a creation 
date because it is known that resource expire after one year) should be 
treated in the same way as if this information would be made available 
directly in the resource's representation."

> Nits/editorial comments:
> 
> The example section could perhaps demonstrate the use of the sunset relation in
> addition to the header field.

good point, i added an example after the header field example.

'Before the Sunset header even appears for the first time (it may not 
appear fro the very beginning), it is possible that the resource (or 
possibly just the "home" resource of the service context) communicates 
its sunset policy by using the sunset link relation. If communicated as 
an HTTP header field, it might look as following:

Link: <http://example.net/sunset>;rel="sunset";type="text/html"

In this case, the linked resource provides sunset policy information 
about the service context. It may be documentation aimed at developers, 
for example informing them that the lifetime of a certain class of 
resources is ten years after creation, and that Sunset headers will be 
served as soon as the sunset date is less than some given period of 
time. It may also inform developers whether the service will respond 
with 410 or 404 after the sunset time, as discussed above.'

thanks again for the review. i'll post an updated version soon.

cheers,

dret.

-- 
erik wilde | mailto:[e-mail] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |