Re: [Netconf] Comments on draft-ietf-netconf-netconf-client-server

[Kent Watsen <[e-mail]>]

[just back from travels]

Hi Ramkumar,


> Comment 1:
> We are using the ‘ietf-netconf-server’ module for configuration of call home parameters
> like netconf client endpoint IP/port, keys/certificates etc..  For static configuration from
> northbound, this works fine.
>
> Our use case is that the netconf client endpoint IP/port are learnt dynamically through
> DHCP process inline with BBF TR301_Issue2.  These dynamically learnt endpoints also
> need to be modelled in the yang.  These dynamic endpoints should also support the
> configuration of keys/certificates.

I just read TR301 Issue2, which is similar to work I do both in and out of the IETF.

What is your question specifically?  Is it how to configure the ietf-netconf-server
data model given the PMA Offer message described in Section 16.5.2.2?  or is
it how the PMA can configure these values after it establishes a NETCONF
connection (via NETCONF Call Home) to the DPU after the discovery process
completes?

[BTW, please notify the editor about the typo in R-191: s/Identified/Identifying/.]


> Comment 2: The server keys/certificates/ca-certs are configurable per endpoint per
> netconf-client. We understand pinned-ca-certs/ pinned-client-certs can be per endpoint.
> But for the device acting as the netconf server, we see only one set of keys/certificates
> is enough and need not be per endpoint.

As I understand TR301, the DPU will perform standard certificate path validation
of the PMA’s end-entity certificate to a per-configured trust-anchor certificate,
presumably one provided by a public CA such as Verisign or Comodo, such as
might be found in, e.g., /etc/ssl/certs.  Thusly, these certs are, in effect, the
“pinned-ca-certs” that would be used.  For absolute correctness, the DPU could
auto-populate /ietf-trust-anchors:pinned-certificates with these certs, or it could
do “backend magic” to achieve the same result.


> Comment 3: The description of ‘netconf-server/listen/endpoint/transport/ssh/address’
> is mentioned as “The NETCONF server will listen on all configured interfaces if no value is
> specified”.  When no value is specified, we are unable to configure ‘ss:ssh-server-grouping’
> parameters.

Good catch, the mandatory true requires a value.  This was discussed on the list a
while back with the result of wanting to instead have the address always specified,
using INADDR_ANY or INADDR6_ANY when needed.  The description statement is
wrong.  I have removed the 2nd sentence from the description statement in six
locations in the four modules ietf-[netconf|restconf]-[client|server] in my local
copy.

BTW, you mention “listen” and “ssh” but, for TR301, it should be “call-home” and
“tls”, right?


Regards,
Kent