Subject: [netconf] Last Call on Re: Today's update to client-server drafts

From: tom petch <[email-masked]>
Date: Fri, 12 Jun 2020 16:30:52 +0000

From: netconf <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Sent: 22 May 2020 06:14

<tp>
I am sure I saw a Last Call but cannot now find it.

I wonder if there is anyone in the IETF who is familiar with this work and with RFC8635;  would these I-D meet the needs of RFC8635 which I have always seen as one of the two use cases for this work?

In passing, trust anchors registers prefix ta; logical except that the I-D uses ts

Tom Petch

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

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

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

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

---

From: Kent Watsen <[email-masked]>
Date: Mon, 15 Jun 2020 14:59:41 +0000

Hi Tom,

> On Jun 12, 2020, at 12:30 PM, tom petch <[email-masked]> wrote:
> 

It looks like you have now found/reply to that thread. :)

> I wonder if there is anyone in the IETF who is familiar with this work and with RFC8635;  would these I-D meet the needs of RFC8635 which I have always seen as one of the two use cases for this wor…

I just read the first couple pages.  Yes, this work, keystore in particular, seems complementary to RFC 8635.  Both the “router-driven” and “operator-driven” methods are supported though, with the recent removal of the key-generation RPCs, the “operator-driven” approach is tempered a bit.

Note that the paragraph at the top of Page 3 mimics Section 5.3 (Migrating Configuration to Another Server) in the keystore draft:

   For example, when an operator wants to support hot-swappable routers,
   the same private key needs to be installed in the soon-to-be online
   router that was used by the soon-to-be offline router.  This
   motivated the operator-driven method.

> In passing, trust anchors registers prefix ta; logical except that the I-D uses ts

Good catch.  Corrected here: https://github.com/netconf-wg/trust-anchors/commit/43017b3a448d46a47526b138df551748b92df146 <https://github.com/netconf-wg/trust-anchors/commit/43017b3a448d46a47526b138df551748b92df146>

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

I recently answered this question for Mahesh here: https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/ <https://mailarchive.ietf.org/arch/msg/netconf/UDNkN5SOmeDaHA5pHYhe-v0l6MI/>

Kent // contributor