Subject: [Trans] [trans] #109 (rfc6962-bis): log shutdown timeline and behavior

From: "trans issue tracker" <[email-masked]>
Date: Sun, 18 Oct 2015 23:52:27 -0000

#109: log shutdown timeline and behavior

 6962-bis currently describes the "Final STH" element of the log's
 metadata.  However, there is no overall description of what the log
 shutdown process should look like from the log operator's point of view.

 6962-bis should include an example timeline of a responsible log shutdown
 as implementation guidance for operators.  Some questions worth answering
 include:

  * how long after shutdown should a responsible log continue publishing?
  * should advance notice of an impending shutdown be given? if so,
     * how long in advance?
     * Is there a mechanism for such notice?
  * for a shutdown log that is still operating, how should it respond to
 requests for new SCTs?  the existing error codes don't seem to indicate an
 option for "this log is shut down and no longer accepting new requests"

 See also #101 for how CT gossip needs to interact with a log that has
 shutdown.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  [email-masked]  |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/109>
trans <http://tools.ietf.org/trans/>

---

From: "trans issue tracker" <[email-masked]>
Date: Mon, 19 Oct 2015 08:29:41 -0000

Changes (by [email-masked]):

 * cc: [email-masked] (added)

 Severity:  -            |  Resolution:
 Keywords:               |

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/109#comment:1>
trans <http://tools.ietf.org/trans/>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 20 Oct 2015 10:42:44 -0400

I think this is an important topic to address and almost all of it
seems appropriate for a log spec.

The primary consumers of log metadata seem to be browsers (via browser 
vendors),
Monitors, and Auditors. I suggest that their requirements for dealing 
with shutdown
ought to be described in the docs that define each of them, not in a log 
spec.

Steve