Current wording (3.8 The animation-delay property):

# The 'animation-delay' property defines when the animation will start. 
# It allows an animation to begin execution some time after it is applied. 
# An 'animation-delay' value of ‘0s’ means the animation will execute as 
# soon as it is applied. Otherwise, the value specifies an offset from 
# the moment the animation is applied, and the animation will delay 
# execution by that offset. 

Proposed wording:

# The 'animation-delay' property defines when the animation's first
# iteration will start. This allows an animation to begin execution 
# some time after it is applied. An 'animation-delay' value of ‘0s’ 
# means the animation will execute as soon as it is applied. Otherwise, 
# the value specifies an offset from the moment the animation is applied, 
# and the animation will delay execution by that offset.

I think it would be useful to mention how negative animation-delay behaves.

The next paragraph covers negative delays:

# If the value for 'animation-delay' is a negative time offset then 
# the animation will execute the moment it is applied, but will appear 
# to have begun execution at the specified offset. That is, the animation 
# will appear to begin part-way through its play cycle. In the case where 
# an animation has implied starting values and a negative 'animation-delay', 
# the starting values are taken from the moment the animation is applied. 


Or do you mean we should cover the case where the delay is > duration AND iteration-count > 1?

"Or do you mean we should cover the case where the delay is > duration AND
iteration-count > 1?"

Clarifying as this may be puzzling: the question here is whether we ought to define what happens when animation-delay <= (-1 x animation-duration); for instance, what happens in cases such as:

animation-duration: 5s;
animation-delay: -5s;

animation-duration: 5s;
animation-delay: -6s;

animation-duration: 5s;
animation-iteration-count: 2;
animation-delay: -6s;

Resolved per 2014-09-09 WG decision.