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

["Rob Wilton (rwilton)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Kent Watsen
Sent: 21 April 2020 15:17
To: Juergen Schoenwaelder <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] Virtual "hum" for the "key generation" issue discussed at virtual meeting

Hi Juergen,

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

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


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.

The presentation begins at the 5:05 mark here: 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.



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.

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.



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

Thanks for sending out the correct link!

Kent