Operations Model for Router Keying
Note: This ballot was opened for revision 09 and is now closed.
( Stewart Bryant ) Yes
( Sean Turner ) Yes
Jari Arkko No Objection
( Richard Barnes ) No Objection
( Gonzalo Camarillo ) No Objection
Benoit Claise No Objection
Comment (2013-12-03 for -09)
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"
Spencer Dawkins No Objection
( Adrian Farrel ) No Objection
Stephen Farrell No Objection
Brian Haberman No Objection
Joel Jaeggli No Objection
Barry Leiba No Objection
Comment (2013-11-15 for -09)
-- 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?
( Ted Lemon ) No Objection
Comment (2013-11-30 for -09)
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?