Re: [karp] Gen-ART review of draft-ietf-karp-crypto-key-table-07

[Sam Hartman <[e-mail]>]

Here are some quick initial responses to your comments.

Thanks much for the review and I'll follow up with more detail in a
while.

>>>>> "Black," == Black, David <[e-mail]> writes:


    Black,> Major issues:

    Black,> (Section 2)

    Black,> [1] LocalKeyName and PeerKeyName are strings.  What
    Black,> character set?  If Unicode (e.g., UTF-8?), add text on
    Black,> Unicode considerations (e.g., normalization).  Finding a
    Black,> Unicode expert will help in getting this done quickly.  I
    Black,> have similar concerns for other strings, and in particular,
    Black,> IANA should be told what a "string" is for any registry
    Black,> field that contains one.

They are strings that can be compared using binary comparison.
I agree we need to state that in the draft.
Character set, to the extent it is specified will be specified by the
individual protocol.
In practice the protocol will say  that it's an integer represented as
an ASCII string.

We needed to add the entire complexity of making these fields be strings
    not integers because of some non-IETF protocols that use key names.

I'm reasonably confident I can sell Pete on the concept of a binary
    identifier for this field from an i18n standpoint.

But issues, of length, format, etc are all specified by the protocol
spec.

    Black,> [2] I'm not sure that I understand what a KDF really is from
    Black,> its high level description in this draft.  At the least, I'm
    Black,> surprised that the importance of non-invertibility of a KDF
    Black,> is not mentioned - beyond that, a functional description of
    Black,> inputs and outputs would help, including a strong
    Black,> recommendation to inject unpredictable nonce material.  This
    Black,> could be handled by referencing material on what a KDF is
    Black,> that exists elsewhere.

I'm open to text either proposed on the IETF list from one of the other
authors.
Some protocols have a KDF input some do not.
If they do, it will be drawn from a set of allowable valuable for that
protocol.

    Black,> (Section 4)

    Black,> [3] It's important that this section cover all the fields
    Black,> involved in the database lookups in Section 3 whose format
    Black,> may be protocol-specific (the Direction and various time
    Black,> fields aren't).  Protocol should be covered by the IANA
    Black,> registry, peers and key names are covered here, but
    Black,> interface appears to be missing - item (9) covers presence
    Black,> vs.  absence of interface information, but not its format.

The interface is implementation-specific not protocol specific.  We
mandate that you must be able to tie things to interface. However the
format of an interface is quite specific to the routing platform in
questino.  I don't think there's a way that an IETF document can go into
useful detail on that.  SNMP and Netconf have models of how interfaces
are represented.  If we ever put together a Netconf schema for this
database, we'd specify the interface there.

    Black,> --- Lots of issues with the IANA Considerations (Section 8)

    Black,> (Section 8.1.1)

    Black,> [5] No field format information for the fields in a registry
    Black,> entry.  IANA should be told what formats to expect/use.

Thanks, agreed.


    Black,> [6] "Protocol Specific Values" is not the same as
    Black,> "ProtocolSpecificInfo" in section 2; the same name should be
    Black,> used, but whitespace differences are ok.
Good catch.

    Black,> [7] Should some sort of formats for Peers and Interfaces be
    Black,> included in registering a Protocol?  If not, the lookups in
    Black,> section 3 may be implementation-dependent (strings that work
    Black,> w/one implementation may not work w/other implementations of
    Black,> the same protocol).  The specification reference may suffice
    Black,> based on the requirements in section 4 for what has to be in
    Black,> each referenced specification.

When you register a protocol you need to point to a specification that
    gives details on this sort of thing.

    Black,> (Sections 8.2 and 8.3)

    Black,> [8] No registry entry content descriptions.  Need to supply
    Black,> information on what to register and the formats of the
    Black,> elements of a registry entry.

Thanks.

    Black,> [9] I suggest Expert Review for these registries, not just
    Black,> First Come First Served, so that someone with a security
    Black,> "clue" can check that the proposed registrations are
    Black,> reasonable.

As an individual, I support FCFS, because I think getting expert
    approval for some of the uses that have been proposed for these
    registries will be challenging.