[karp] Some comments to the draft-ietf-karp-crypto-key-table-04.txt

[Tero Kivinen <[e-mail]>]

In section 2:

      RcvNotAfter
         The RcvNotAfter field specifies the latest date and time at
         which this key should be considered for use when processing
         received traffic.  The format of this field is identical to the
         format of NotBefore.
		   ^^^^^^^^^

That NotBefore should be RcvNotBefore.

--

In section 6 it says:

			When installing a series
   of keys to be used one after another (sometimes called a key chain),
   operators should configure the SendNotBefore field of the key to be
   several days after the RcvNotBefore field of the key to address the
   clock skew issue and guarantee there is some overlap.

If some routers have clock skew that is in order of DAYS and we need
to have keys overlapping for "several days" to fix that, I think there
might be something wrong with the router... Clock skew should be less
than few minutes. There might be operation reasons to support multiple
days of overlap, but on the other hand if those keys are already
configured in the keytable beforehand and they are taken in to use
automatically from there, I do not think we need days of overlap.

If it is assumed that sometimes the adminstrators starts to type keys
in to the keytable only when it gets close to be expiring then this
might be useful, but I do not think this is something that is supposed
to be done with keytable.

-

In section 8.3

8.3. KeyTable AlgIDs

   This document requests establishment of a registry called "KeyTable
   AlgIDs".  The remainder of this section describes the registry.

   All assignments to the KeyTable KDFs registry are made on a First
			  ^^^^^^^^^^^^^
   Come First Served basis per Section 4.1 of RFC 5226.

The KeyTable KDFs should be KeyTable AlgIDs in this section, the KDFs
was 8.2...
-- 
[e-mail]