-- Section 8 --

   Time is used to control when keys MAY
   begin being used and when they MUST NOT be used any longer

Take or leave this: The 2119 language seems odd here; this isn't putting normative requirements on anything, but is describing a situation.  I would lowercase the words.

   If time synchronization is too loose, then a key can be
   used beyond its intended lifetime.

How significant is that, really?  How much does it matter if a key is used for a few seconds longer than intended?  Is it worth saying a few words about that, in regard to keeping time synched to seconds, or milliseconds, or minutes?

   Similarly, designing and deploying the protocol will be easier with
   thought paid to a common operational model. 

I applause this approach! 

- Section 3.2
Several management operations will be quite common.

Operations is misleading: SNMP-GET and SNMP-SET are two (SNMP) operations.
I think you mean: 
	(1) several management interfaces will be quite common
	or 
	(2) several configuration interfaces will be quite common
(1) is my preferred option since this term is used multiple times throughout the draft.

- Section 3.2

   The management interface SHOULD
   provide a mechanism to easily update the expiration time for a
   current key used with a given peer or interface.  Also when adding a
   key it is desirable to push the key out to nodes that will need it,
   allowing use for receiving packets then later enabling transmit.
   This can be accomplished automatically by providing a delay between
   when a key becomes valid for reception and transmission.  However,
   some environments may not be able to predict when all the necessary
   changes will be made.  In these cases having a mechanism to enable a
   key for sending is desirable.  Management interfaces SHOULD provide
   an easy mechanism to update the direction of an existing key or to
   enable a disabled key.

Be consistent between "the management interface" versus "management interfaces" 

- Wonder why sometimes peer is capitalized?

-  Some idnits
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-karp-ops-model-09.txt

- A customer router that is an an insider for a BGP peering

- Section 7

   For peer-to-peer protocols such as BGP, this can be relatively easy.

Not sure what "this" is about. It doesn't connect with the previous paragraph. 
I guess you mean "key upgrade"

In 3.1:
   o  The direction is valid for the protocol; for example protocols
      that require the same session key be used in both directions MUST
      have a direction of both.

Isn't the thing that must have the direction of "both" the table entry, not the protocol?   IOW:

   o  The direction is valid for the protocol; for example, table
      entries for protocols that require the same session key be
      used in both directions MUST have a direction of both.

In 4.1:

   The key point is that whenever the same key is used in multiple
   protocols, attacks may be possible.

HA!

Shouldn't 4.3 talk about certificate revocation?