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

["t.petch" <[e-mail]>]

Spencer

Perhaps one for a Note to the RFC Editor

-12 still has
         bit unauth-test-encrpyt-control {
which AM suggested should be
         bit unauth-test-encrypt-control {

Tom Petch

----- Original Message -----
From: "Spencer Dawkins at IETF" <[e-mail]>
To: "Ignas Bagdonas" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>; "IESG" <[e-mail]>
Sent: Thursday, June 28, 2018 3:24 PM

> 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.
>