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

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Spencer,

From: Spencer Dawkins at IETF [mailto:[e-mail]]
Sent: Thursday, June 28, 2018 10:25 AM
To: Ignas Bagdonas <[e-mail]>
Cc: Mahesh Jethanandani <[e-mail]>; [e-mail]; [e-mail]; IESG <[e-mail]>; [e-mail]; Nalini Elkins <[e-mail]>
Subject: Re: Ignas Bagdonas' Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)

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]<mailto:[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).
[acm]
That’s exactly how I described what I did when the authors first
discussed the topic, and again in reply to Ignas’ DISCUSS.
Another aspect was the overlapping development of the model memos.
I don’t have a problem qualifying what we did here,
as an explanation. As Ignas points out, there is a larger
model problem to solve.

Al

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.