Subject: [netconf] Today's update to client-server drafts

From: Kent Watsen <[email-masked]>
Date: Wed, 20 May 2020 21:30:16 +0000

The entire suite of drafts were updated today.
The first three drafts are ready for WGLC.
All of the other drafts are almost ready for WGLC.
Below is the Change Log entry for each draft.

K.

For all drafts:

   o  Added a "Note to Reviewers" note to first page.

For crypto-types:

   o  Removed the IANA-maintained registries for symmetric, asymmetric,
       and hash algorithms.

   o  Removed the "generate-symmetric-key" and "generate-asymmetric-key"
       RPCs.

   o  Removed the "algorithm" node in the various symmetric and
       asymmetric key groupings.

   o  Added 'typedef csr' and 'feature certificate-signing-request-
      generation'.

   o  Refined a usage of "end-entity-cert-grouping" to make the "cert"
       node mandatory true.

For trust-anchors:

   o  Removed "algorithm" node from examples.

   o  Removed the no longer used statements supporting the old "ssh-
       public-key" and "raw-public-key" nodes.

For keystore:

   o  Removed augments to the "generate-symmetric-key" and "generate-
       asymmetric-key" groupings.

   o  Removed "generate-symmetric-key" and "generate-asymmetric-key"
       examples.

   o  Removed the "algorithm" nodes from remaining examples.

   o  Renamed/updated the "Support for Built-in Keys" section.

   o  Added new section "Encrypting Keys in Configuration".

For tcp-client-server:

   o  Removed commented out "grouping tcp-system-grouping" statement
       kept for reviewers.

For ssh-client-server:

   o  Updated the "keepalives" containers to address Michal Vasko's
       request to align with RFC 8071

   o  Removed algorithm-mapping tables from the "SSH Common Model"
       section

   o  Removed 'algorithm' node from examples.

   o  Added feature "client-identity-publickey"

   o  Removed "choice auth-type", as auth-types aren't exclusive.

   o  Renamed both "client-certs" and "server-certs" to "ee-certs"

   o  Switch "must" to assert the public-key-format is "subject-public-
       key-info-format" when certificates are used.

For tls-client-server:

   o  Updated the "keepalives" containers in part to address Michal
       Vasko's request to align with RFC 8071 and in part to better align to RFC 6520

   o  Removed algorithm-mapping tables from the "TLS Common Model"
       section

   o  Removed the 'algorithm' node from the examples.

   o  Renamed both "client-certs" and "server-certs" to "ee-certs"

For http-client-server:

   o  Removed "protocol-versions" from ietf-http-server based on HTTP WG
       feedback.

   o  Slightly restructured the "proxy-server" definition in ietf-http-
       client.

   o  Added http-client example show proxy server use.

For netconf-client-server:

   o  Updated examples to remove the 'algorithm' nodes.

   o  Updated examples to reflect the new TLS keepalives structure.

   o  Added keepalives to the tcp-client-parameters section in the
       netconf-server SSH-based call-home example.

   o  Added a TLS-based call-home example to the netconf-client example.

For restonf-client-server:

   o  Updated examples to remove the 'algorithm' nodes.

   o  Updated examples to reflect the new TLS keepalives structure.

   o  Removed the 'protocol-versions' node from the restconf-server
       examples.

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 21 May 2020 22:14:04 -0700

What would it take to get the remaining drafts into WGLC?

> On May 20, 2020, at 2:30 PM, Kent Watsen <[email-masked]> wrote:
> 
> 
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

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

---

From: Kent Watsen <[email-masked]>
Date: Fri, 22 May 2020 16:40:57 +0000

Hi Mahesh,

> What would it take to get the remaining drafts into WGLC?

The pending activities are:

    - tcp-client-server: 
        - finalize proxy solution
    - ssh-client-server: 
        - discuss issues with the 'ssh-host-keys' node
    - tls-client-server: 
        - discuss issue with the 'ee-certs' node
        - discuss issue with the psk 'id' type
    - http-client-server:
        - finalize proxy solution
        - finalize security considerations

We're currently 7 weeks out from the 108 draft cutoff, and 9 weeks out from the conference itself.  It would be nice to do something like this:

    - now:     start 2-wk LC for ct/ts/ks
    - in 2wks: start 1-wk LC for tcp 
    - in 3wks: start 2-wk LC for ssh/tls
    - in 5wks: start 1-wk LC for http
    - in 6wks: start 2-wk LC for nc/rc
    - end all LC in 8wks.

But that is only possible if (1) we're able to resolve all the pending items while simultaneously doing LCs on the earlier drafts...or (2) folks are willing to provide reviews on the drafts as they are, in part helping to close the pending activities.

Another option would be to (3) just do:

    - now: start 2-wk LC for ct+ts+ks
    - after resolving pending issue: start 2-wk LC for tcp
    - update all drafts based on the fallout of above reviews
    - present remaining open issues at 108 
    - update remaining drafts accordingly
    - resume the LCs shortly after 108

I prefer (2) or (3), as (1) puts too much work on me in a short period of time, and I have a big deliverable coming up in my other life outside the IETF.

K.