Subject: [netconf] Virtual hum on the question of keygen

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 8 May 2020 12:25:02 -0700

[Sorry if this e-mail appears multiple times. I seem to be having issues
with Google's SMTP server]

This e-mail closes the virtual hum on the question of keygen as it relates
to draft-ietf-netconf-crypto-types.

The poll was a weighed average poll, with folks asked to order their
preferences. The overall results of the poll did not indicate a clear
consensus. The tie was between keeping keygen and support at SSH/TLS layer,
and not supporting keygen at this time, with the latter having a slight
preference. What was interesting about the poll was an overwhelming support
for not supporting keygen at this time as the first preference, with the
2nd option more evenly weighed between first and second preference.

As explained before not supporting keygen at this time does not preclude it
from being added later on. The WG has indicated a desire to get this work
done soon, which may be why the 3rd option may be carrying more support.

At this point with no clear consensus, I am going to make it authors
decision.

Thanks.

Mahesh Jethanandani (as co-chair)
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Fri, 8 May 2020 21:18:08 +0000

> On May 8, 2020, at 3:25 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> [Sorry if this e-mail appears multiple times. I seem to be having issues with Google's SMTP server]
> 
> This e-mail closes the virtual hum on the question of keygen as it relates to draft-ietf-netconf-crypto-types.
> 
> The poll was a weighed average poll, with folks asked to order their preferences.. The overall results of the poll did not indicate a clear consensus. The tie was between keeping keygen and support at SSH/TLS layer, and not supporting keygen at this time, with the latter having a slight preference. What was interesting about the poll was an overwhelming support for not supporting keygen at this time as the first preference, with the 2nd option more evenly weighed between first and second preference.
> 
> As explained before not supporting keygen at this time does not preclude it from being added later on. The WG has indicated a desire to get this work done soon, which may be why the 3rd option may be carrying more support.
>  
> At this point with no clear consensus, I am going to make it authors decision.

As author, primarily interested in reducing my personal/self-funded/ongoing involvement in this sprawling effort, and partially believing that others (upon realizing the important keygen) will pick it and (upon attracting greater buy-in/involvement from key stakeholders than I've been able to manage) produce a better and more meaningful result, I therefore choose to proceed with Option 3 (i.e., to NOT support keygen at this time).

Kent // as author

> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf