Re: [netconf] Warren Kumari's No Objection on draft-ietf-netconf-keystore-30: (with COMMENT)

[Warren Kumari <[e-mail]>]

On Wed, Jan 31, 2024 at 5:00 PM, Kent Watsen <[e-mail]> wrote:

> Hi Warren,
>
> Thank you for you valuable comments.
> Please find below my responses.
>
> Kent
>
> On Jan 30, 2024, at 7:29 PM, Warren Kumari via Datatracker <noreply@ietf.
> org> wrote:
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-netconf-keystore-30: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/
> handling-ballot-positions/ for more information about how to handle
> DISCUSS and COMMENT positions.
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-keystore/
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Roman's DISCUSS.
>
> Also, when reading this document I initially got excited, thinking that
> I'd find more text on the 'hidden keys', but my excitement was short
> lived...:-)
>
> Sorry to disappoint! ;)
>
> Assuming you add text to the other YANG crypto types document, perhaps you
> can include it here too?
>
> Unlike the “crypto-types” draft, this draft has a dedicated section called
> "Support for Built-in Keys”, is it not enough?
>
> One thing I noticed was that this section doesn’t ever use the word
> “hidden”, though it’s mostly the case that they would be hidden, though
> they could possibly be “encrypted”, though it may not be worth saying that.
>
> This being the case, how about this edit?
>
> OLD: Built-in keys are expected to be set by a vendor-specific process.
> NEW: Built-in keys are "hidden" keys expected to be set by a
> vendor-specific process.
>


Thank you, that helps…

W




> Thanks again!
> Kent
>