Note: This ballot was opened for revision 09 and is now closed.
Summary: Needs a YES.
-- 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
(2) several configuration interfaces will be quite common
(1) is my preferred option since this term is used multiple times throughout
- 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
- 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"
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
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.
The key point is that whenever the same key is used in multiple
protocols, attacks may be possible.
Shouldn't 4.3 talk about certificate revocation?