Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
draft-ietf-ipsecme-ikev2-resumption-09

I'm assuming that the malicious corrpution or deletion of stored tickets has only a small disruptive affect on session recovery. That is, an attempt will be made to recover the ticket before dropping abck to the current processing rules (pre-this-draft).
---
The use of ! rather than | in protocol object figures is unusual, but not illegal.
---
Section 7 identifies the different notification messages by "notification numbers" but the subsequent subsections (7.1 etc.) use the term "Notify Message Type". According to the IANA section and the registry, the latter term is correct.

This is a useful document.
Some minor comments/questions below:

4.3.1.  Prologue

   Tickets are intended for one-time use, i.e. a client MUST NOT reuse a
   ticket.  A reused ticket SHOULD be rejected by a gateway.  Note that
   a ticket is considered as used only when an IKE SA has been
   established successfully with it.

Isn't this a recipe for DoS attacks?


7.1.  TICKET_LT_OPAQUE Notify Payload

   The data for the TICKET_LT_OPAQUE Notify payload consists of the
   Notify message header, a Lifetime field and the ticket itself.  The
   four octet Lifetime field contains a relative time value, the number
   of seconds until the ticket expires (encoded as an unsigned integer).

I suggest saying that the Lifetime is encoded in network byte order.

Michael Sneed notes in his OPS-DIR review the following: 

Section 9.1 of the "Security Considerations"  could use some clarification: the inability of an attacker to use a stolen unencrypted "ticket by reference" is explained as "for the same reasons as for a ticket by value", but for a "ticket by value" the explanation is that the ticket is encrypted.

INTRODUCTION, paragraph 13:
> Abstract

  Is long, and overlaps with the introduction a lot.

Well-written and understandable doc.  I have one small editorial comment:

From section 5:

   Note 1:  The authenticated peer identity used for policy lookups may
            not be the same as the IDi payload (see Sec. 3.5 of
            [RFC4718]), and if so, MUST be included in the ticket.  Note
            that the client may not have access to this value.

What is the condition to be checked by "if so" and what is to be included based on that condition?  It would be clearer to include text that explicitly describes the condition and what is to be included.