Re: [secdir] draft-ietf-karp-crypto-key-table-07

["Klaas Wierenga (kwiereng)" <[e-mail]>]

On Apr 19, 2013, at 4:22 PM, Sam Hartman <[e-mail]> wrote:

>>>>>> "Klaas" == Klaas Wierenga (kwiereng) <[e-mail]> writes:
> 
> 
>    Klaas> * 1 Intro
> 
>    Klaas> What is conceptual about it? Isn't this supposed to be a
>    Klaas> specification of the format for a real database?
> 
> No.
> It's exactly to avoid getting into a discussion of normalization and
> most of the comments you discuss in your comments on section two that we
> want this to be conceptual.
> We don't want to go there because there is no interoperability advantage
> to specifying things at that level of detail .
> 
>    Klaas> * 2 Conceptual Database Structure
> 
>    Klaas> introductory paragraph: it is hard to grasp why or why not
>    Klaas> you want to have the same key appear twice without
>    Klaas> understanding what the format of the database will look
>    Klaas> like. So I think you should move that part of the first
>    Klaas> paragraph to below the column definition.
> 
>    Klaas> Peers: hmm, so now you have a multivalued column of arbitrary
>    Klaas> length? What is the separator? And do you expect
>    Klaas> normalisation into separate tables to happen?
> 
> Since we're a conceptual database we don't need to answer any of that:-)

hmm ok, I see your point

> To describe the key selection algorithm we need to say it's a set.
> To have interoperability within protocols we need each protocol to
> define the format of a member of the set, but *not* how to represent a
> set as a whole.
> 
> If we defined a netconf schema we might well need to define  how to add
> and remove members from this set.
> 
> The natural way to do this will be vendor specific; the way I'd define a
> IOS-style CLI would be very different than what I'd do for something
> grabbing configuration from an SQL database.
> 
> 
>    Klaas> Protocol: So here you want only a single security protocol,
>    Klaas> resulting in rows with the same key but different
>    Klaas> protocols. Resulting in a more complex lookup but no
>    Klaas> normalisation into separate tables necessary, I'd say best to
>    Klaas> choose one solution and stick to it.
> 
> In general, the protocol value is very likely to influence what keys are
> valid.
> We also want to strongly discourage the same key being used between
> protocols.

Yes, I understand that argument, but….. just like with peers you can argue that you don't have to answer any questions about whether you want extra records or multiple protocols per key in 1 record. It just suffices to say that you discourage the use of the same key for multiple protocols. Anyway, I don't feel strongly about this, it just felt inconsistent.

Klaas