Re: [ippm] Ignas Bagdonas' Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF <[e-mail]>]

Dear Authors,

Thank you for a quick and productive Discussion on Ignas's ballot position
on this draft.

On Tue, Jun 26, 2018 at 11:32 AM Ignas Bagdonas <[e-mail]> wrote:

> >> 3. Key storage. The document defines its own way of storing keys -
> while there
> >> are multiple existing ways to store keys (routing key-chain model,
> I2NSF, IPsec
> >> model, netconf-keystore). Why yet another key storage mechanism is
> required?
> >> What could be reused from other existing mechanisms?
> > Precisely. When we started work on this draft, there were plethora of
> ideas on how to store keys. We borrowed the idea from what is now the
> ietf-key-chain module to define the key chain. And we followed the KISS
> principle by incorporating what was absolutely needed by TWAMP.
>
> That is understood and probably can be justified for this particular
> model. But the cost of this approach is yet another way of storing key
> information.
>

I saw that Ignas cleared his Discuss here, but did have a question about
where the resolution ended up.

I understood Ignas to be asking two things - where did this way of storing
keys come from, and why was an existing way of storing the keys not chosen?

I understand that Ignas cleared his Discuss, based on the explanation in
this e-mail thread.

I wonder if it is worth a sentence or two, to explain that in the draft
("we started with this key storage model, and left out parts we didn't
need", or something like that).

I'm reviewing changes today, so expect to be sending the e-mail approving
publication pretty soon.

Spencer


> > Having the answers for the three points that you have raised, would you
> still have a DISCUSS. If so, which issue, do you want to see addressed?
>
> I am happy with the answers, will clear the DISCUSS. The one that I am
> somewhat less happy with is the key storage one - from the perspective
> of both model developer and application developer, additional model that
> does mostly the same thing is getting towards both to the duplication of
> the work and encouraging the divergence of the ways how similar things
> are done. The root of the problem is far deeper than this draft - there
> does not appear to be an overall coordination of how the different
> models bind together into something that allows to use different models
> in the context of the whole system.
>