Subject: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting

From: Kent Watsen <[email-masked]>
Date: Mon, 20 Apr 2020 22:55:11 +0000

NETCONF WG,

The chairs have created an ANONYMOUS poll to ask the WG to rank the 3 options discussed during the virtual interim.  Please submit your response within 1-week (7 days):

	https://www.surveymonkey.com/r/PQZK6DP <https://www.surveymonkey.com/r/PQZK6DP>

Below is the slide that captures the options.  At bottom is the link to the whole PPTX file.

Direct link the whole PPTX: https://datatracker.ietf.org/meeting/interim-2020-netconf-01/materials/slides-interim-2020-netconf-01-sessa-chair-slides.pptx

PS: in case not obvious, this regards the “crypto-types” / “client-server” suite of drafts.

Thanks you!
The NETCONF Chairs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Apr 2020 08:39:56 +0200

> Below is the slide that captures the options.  At bottom is the link to the whole PPTX file.

So what do the numbers mean? 1 = highest priority or 1 = lowest
priority?

Can you explain what 'fastest closure' means? What is your estimate
of the time difference between otions #3 and #2? There is a big
difference for me between lets say 3 months and 2 years.

On the list, it was already said that #2 be done later if we do
#3. Let me refine this question. Can #2 be done later via an
augmentation? If so, we may do #3 and work on #2 concurrently.  But it
all boils down to what the estimate of the time delta between #2 and
#3 is.

The proper link to the slides seems to be:

https://datatracker.ietf.org/meeting/interim-2020-netconf-01/materials/slides-interim-2020-netconf-01-sessa-status-and-issues-for-the-client-server-suite-of-drafts.pptx

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 21 Apr 2020 14:16:54 +0000

Hi Juergen,

> So what do the numbers mean? 1 = highest priority or 1 = lowest

In the SurveyMonkey interface:

  1 = 1st choice / preference
  2 = 2nd choice / preference
  3 = 3rd choice / preference

If using the drag-n-drop ability, the top-most row is the 1st choice.  SurveyMonkey will nicely automatically assign it the value ‘1’.   Sadly, when setting the values directly, SurveyMonkey inconsistently does not reorder the rows...

> difference for me between lets say 3 months and 2 years.

The presentation begins at the 5:05 mark here: https://www.youtube.com/watch?v=-OByWiciRrc <https://www.youtube.com/watch?v=-OByWiciRrc>.

Fastest closure is just me deleting stuff from the crypto-types, keystore, ssh-client-server, and tls-client-server drafts (1 week?) at which point I think we could start a WGLC.

Options #1 and #2 both have uncertain endings.  In theory, Option 1 is done (just a little clean up), but SecDir and SecAD think it might blow up in IESG review.  Option 2 has less blow up potential, but as it hasn’t been worked on yet, it’s unclear how it might land, and then there is labor effort, for which I get little help.   In either case, it wouldn’t surprise me at all if we were still talking about them a year from now.

> all boils down to what the estimate of the time delta between #2 and

Both #1 and #2 could equally well be done later if we do #3 now.  Stated another way, picking #3 doesn’t cause us to do anything that might preclude or complicate doing #1 or #2 later.  Rather, it’s more akin to doing nothing, leaving a void that could be filled in either way when the time arises.

Since the crux of YANG modules is the definition of groupings, I imagine “-bis" RFCs needing to be published, more so than having other RFCs augment the groupings.  This being the case, working of concurrent publications doesn’t seem feasible to me. 

> https://datatracker.ietf.org/meeting/interim-2020-netconf-01/materials/slides-interim-2020-netconf-01-sessa-status-and-issues-for-the-client-server-suite-of-drafts.pptx <https://datatracker.ietf.org/meeting/interim-2020-netconf-01/materials/slides-interim-2020-netconf-01-sessa-status-and-issues-for-the-client-server-suite-of-drafts.pptx>

Thanks for sending out the correct link!

Kent

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 27 Apr 2020 16:41:36 +0000

Hi Kent,

Having just watched the video again, and read your comments below, I’m concerned that (1) might not really be a valid option, especially if this means that it would be likely to blow up in the IESG Secdir reviews.

I prefer the 2nd choice from a technical POV:

  *   Using identities rather than enums feels more flexible/extensible.
  *   Having per protocol identities seems to more closely match the status quo, and it doesn’t seem to be a given that all protocols will necessarily want to support all crypto-types.  E.g. a new protocol may choose to only support a subset.  I mean this separately to what subset of crypto types a protocol implementation may choose to support.
  *   It also seems more user friendly to me to have the RPCs defined under the protocols, and having the RPCs defined does seem important/useful.

One question I have, is whether the crypto-types could still define identities for the base algorithms.  The protocol specific identities could optionally derive from a base algorithm identity and a protocol specific identity.  This might then give you the “basic algorithms are the same, but can be used/interpreted slightly differently by different protocols”.

I know that you are busy, do you think that it would be feasible to (2) and then go to WG LC (e.g. before IETF 108)?  I.e. use WG LC as a forcing function to resolve any remaining issues.  Or is there too much work?

Rob,
[As an individual contributor]

From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 21 April 2020 15:17
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting

Hi Juergen,

The presentation begins at the 5:05 mark here: https://www.youtube.com/watch?v=-OByWiciRrc.

Kent